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1.  INTRODUCTION 

1.1  Authority 

Work  was  accomplished  under  STARS  Contract  F19628-88-D-0031,  Delivery  Order  CX)05,  BOA 
#3695.STARS-045,  Reusable  Software  Acquisition. 

1.2  Scope 

In  today’s  acquisition  environment,  software  is  continually  cited  as  the  critical  path  to  program 
success  in  terms  of  capabilities,  budget  and  schedule.  This  increasing  dependence  of  Department 
of  Defense  (DoD)  programs  on  software  development  efforts  dictates  that  software  design  issues 
must  begin  to  incorporate  the  benefits  of  reusable  and  commercially  available  software. 
Breakthrough  initiatives  in  the  way  DoD  administers  developmental  software  and  uses 
commercially  available  software  must  be  incorporated  into  the  federal  acquisition  process  if  the 
full  potential  of  the  Software  Technology  for  Adaptable,  Reliable  Systems  (STARS)  program  is 
to  be  realized.  We  believe  the  STARS  environment  would  be  significantly  enhanced  if  the 
software  acquisition  process,  with  regard  to  reusable  software  and  commercially  available 
software,  were  given  full  consideration. 

1.3  Overview 

Development  of  software-intensive  systems  in  the  DoD  is  typically  characterized  by  programming 
of  new  software  code.  Even  a  cursory  review  of  programs  within  a  given  functional  area 
suggests  that  some  level  of  commonality  exists.  Despite  this  commonality,  acquisition  experience 
has  demonstrated  that  new  programs  focus  almost  entirely  on  new  software  development.  In 
general,  reuse  is  not  addressed  in  Government  Requests  for  Proposal  (RFPs),  contractor  proposals 
or  contracts.  Incentives  are  not  provided  to  software  developers  to  engineer  reusability  into  their 
products. 

1.4  Executive  Summary 

1.4.1  Current  FAR  Environment  and  Proposed  Changes  (see  Section  3.0) 

The  Federal  Acquisition  Regulation  (FAR)  and  DoD  FAR  Supplement  (DFARS),  as  well  as 
service  and  agency  supplements  to  the  FAR,  have  been  examined  for  impediments  in  the  way 
data  rights  are  acquired  and  software  is  contracted.  The  current  FAR  environment  with  regard 
to  software  development,  software  reusability,  and  the  use  of  commercially  available  software 
has  been  documented  in  this  Current  FAR  Environment  repon.  Initial  proposed  changes  to  the 
FAR  and  proposed  FAR  language  changes  have  also  been  incorporated. 

1.4.2  Current  Budget/Finance  Environment  and  Proposed  Changes  (see  Section  4.0) 

Budgeting  and  program  financial  regulations  have  been  reviewed  to  identify  unnecessary  cost 
restrictions  and/or  disincentives  to  providing  financial  resources  for  engineering  software 
reusability  and  use  of  commercially  available  software.  The  current  budget  and  program 
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financing  rcgulatoi7  environment  with  regard  to  software  development,  software  reusability,  and 
the  use  of  commercially  available  software  are  documented  in  this  Current  Budget/Finance 
Environment  report  Proposed  changes  have  been  recommended. 

2.  BACKGROUND 

2.1  Current  Software  Acquisition  Environment 

The  current  sofnvare  acquisition  environment  is  not  compatible  with  the  advanced  concepts 
proposed  by  ihe  STARS  program.  Acquisition  program  offices  cannot  effectively  incorporate 
reuse  requirements  into  contracts.  Software  developers  receive  no  incentives  to  either  produce 
reusable  code  or  to  incorporate  reusability  into  their  design  effons.  The  acquisition  community 
must  adapt  to  accept  reusability  concepts. 

2.2  Goal 

Our  goal  is  to  enhance  opportunities  for  software  reusability.  We  plan  to: 

(a)  Define  the  current  FAR  and  budget/finance  environment 

(b)  Identify  existing  barriers  to  reuse  of  software 

(c)  Incorporate  the  advanced  concepts  of  STARS  into  the  formal  acquisition 
environment 

(d)  Address  reusability  in  software  acquisitions 

(e)  Quantify  software  reusability  benefits  into  source  selection  criteria 

(f)  Incorporate  reusability  into  the  formal  budget  process 

(g)  Identify  opportunities  to  institutionalize  the  concept  of  reusability 

(h)  Propose  FAR  changes  to  increase  reusability 

(i)  Propose  budget/finance  changes  to  increase  reusability 

0)  Support  a  reusability  environment  in  which  both  Government  and  industry  benefit. 

2.3  Approach 

Incentives  must  be  established  to  reward  contractors  who  engineer  reusability  into  their  software 
development  life  cycle.  This  will  require  the  identification  and  modification  of  any  regulation, 
policy  or  procedure  which  impedes  the  establishment  of  such  incentives.  Government  and 
industry  software  developers  and  Government  acquisition  personnel  will  be  interviewed.  The 
FAR  and  DFARS  as  well  as  service  and  agency  supplements  will  be  examined  for  impediments 
in  the  way  data  rights  are  acquired  and  software  is  contracted.  Budgeting  and  program  financing 
regulations  and  policies  will  be  reviewed  to  identify  unnecessary  restrictions  and/or  disincentives 
to  providing  financial  resources  for  engineering  software  reusability.  Procedures  and  processes 
for  providing  program  direction  and  acquisition  strategy  guidance  will  be  examined  for 
opportunities  to  emphasize  and  institutionalize  the  concept  of  engineered  software  reusability. 
This  will  include  techniques  such  as  issuing  license  rights  to  developing  contractors  and 
providing  other  business  incentives  to  stimulate  commercial  custodianship  and  marketing  of 
reusable  software. 
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3.  FAR  ENVIRONMENT 

3.1  The  Current  FAR  Environment  and  Proposed  Changes 

3.1.1  Introduction 

Any  discussion  of  software  reuse  must  ultimately  include  business  considerations.  These  include 
questions  of  ownership,  liability  and  incentives  to  create  reusable  software  and/or  actually  reuse 
existing  software  within  the  Department  of  Defense  (DoD).  The  subject  of  rights  to  software  is 
covered  in  DoD  Federal  Acquisition  Regulation  Supplement  (DFARS),  Pan  227,  Subpan  227.4. 
The  current  DFARS  coverage  was  published  as  an  Interim  Rule  in  1988  and  remains  so  today. 
It  has  received  such  extensive  comment  from  industry  and  Government  that  on  15  October  1990, 
a  new  advanced  notice  of  proposed  rulemaking  was  published.  The  advanced  notice  provides 
revised  coverage  for  comment  prior  to  actually  publishing  a  new  interim  rule.  We  comment  on 
the  advanced  notice  in  this  report. 

Creating  a  software  reuse  acquisition  strategy  requires  an  understanding  of  the  regulatory 
documents  covering  software.  Reuse  strategy  is  affected  by  the  following  considerations:  who 
owns  or  will  own  the  software;  what  kind  of  rights  are  available  in  reusing  the  software;  how 
these  rights  can  be  protected  and  enforced;  what  one  can  do  (inccntivize)  to  create  an 
environment  where  reuse  is  encouraged  and  rewarded;  and  what  liabilities  may  exist  if  a  party 
actuall>  reuses  software.  V/hat  follows  is  an  initial  discussion  of  the  current  FAR/DFAR^: 
environment.  We  follow  with  considerations  one  must  keep  in  mind  when  developing  icuse 
strategy  We  have  also  included  discussion  of  Part  27  of  the  FAR  itself  (and  in  limited  focus. 
National  Aeronautics  and  Space  Adntinistration  (NASA)  regulations)  to  show  some  differences 
between  DoD  and  the  other  executive  agencies.  While  all  other  agencies  follow  FAR,  Pan  27, 
DoD  has  created  DFARS,  Part  227  to  fit  its  unique  requirements.  The  DoD  policy  for  doing  so 
is  stated  in  DFARS  227.472.  We  note,  however,  that  DFARS,  Part  27  reflects  a  more 
conservative  approach  to  determining  Government  interest  in  software  rights  than  does  the  FAR. 
We  will  address  these  differences  in  our  discussion. 

3.U  The  Current  FAR/DFARS  Environment 

Whether  or  not  one  agrees  with  its  contents,  there  is  little  argument  that  today’s  DFA.RS  coverage 
on  software  and  software  rights  is  not  well  written,  is  poorly  organized  and  very  difficult  to 
understand.  While  the  FAR  coverage  is  not  perfect,  going  from  DFARS,  Part  227  to  FAR,  Part 
27  is  anrJogous  to  being  lost  in  the  darkness  of  the  forest  and  suddenly  discovering  a  trail  leading 
to  a  valley  of  light.  You  may  not  yet  know  where  you  arc,  but  your  confidence  in  finding  a  way 
out  increases  dramatically  because  you  can  see  things  much  more  clearly.  Issues  become 
unnecessarily  complicated,  because  neither  the  DFARS  nor  the  FAR  treat  software  separated 
from  technical  data.  Each  has  a  basic  clause  (DFARS  252.227-7013,  Rights  in  Technical  Data 
and  Computer  Software;  FAR  52.227-14,  Rights  in  Data)  addressing  bc'h  subjects.  However, 
technical  data  and  computer  software  are  very  different.  This  commingling  in  a  single  clause, 
we  believe,  exacerbates  confusion  in  the  treatment  of  software  versus  technical  '^ata. 


3 


30  March  1991 


STARS-SC-03501AX)1/[X) 
STARS-SC-03504A)0 1  AX) 


3.U.1  Software:  Definitions  and  Ownership  Categories 

The  DFARS  identifies  three  categories  of  software:  commercial,  unpublished  and  Government 
software.  Table  1-1  includes  extracts  from  the  DFARS  and  FAR  definitions  for  these  terms  and 
for  restricted  rights  software.  Succinctly  stated,  commercial  software  includes  well-Fnown 
products  such  as  LOTUS  1-2-3;  unpublished  software  is  a  product  not  yet  released  (with  or 
without  restrictions)  by  its  owner,  and.  Government  software  is  all  software  developed  or  required 
in  the  performance  of  a  Government  contract  or  subcontract.  Unpublished  software  becomes 
Government-owned  software  if  it  is  created  during  and  required  for  Government  contract 
performance,  even  if  the  contractor  fully  funded  its  development  This  is,  perhaps,  the  most 
contentious  issue  between  Government  and  industry  today  in  the  debate  concerning  necessary 
DFARS  changes.  We  will  discuss  this  issue  again  when  addressing  DoD  policy  regarding 
acquisition  of  rights  in  computer  software.  In  the  definition  of  Government  computer  software, 
the  FA.R  includes  related  documentation,  giving  it  the  same  status  as  software  when  determining 
software  rights  to  be  acquired.  Conversely,  the  DFARS  treats  this  documentation  as  technical 
data,  requiring  a  different  assignment  of  rights.  For  example,  under  the  FAR,  restricted  rights 
software  (Table  1-1)  would  include  the  computer  programs,  databases  and  documentation.  In 
contrast,  the  DFARS  creates  two  environments:  one  for  restricted  rights  software  and  one  for  its 
supporting  documentation,  which  would  be  categorized  as  limited  rights  data.  Thus,  industry  is 
forced  to  think  and  react  differently  when  dealing  with  the  DoD  versus  all  other  federal  agencies. 

3.U.2  Government  Versus  Private  Funding  of  Software  Development 

Prior  to  discussing  policy  for  software  acquisition,  it  is  important  to  first  identify  the  sources  of 
funding  for  software  development.  DFARS  227.471  and  252.227-7013  address  Government  and 
private  funding,  while  DFARS  227.472-3  discusses  mixed  funding.  These  funding  sources  are 
synopsized  below: 

(a)  Developed  Exclusively  with  Government  Funds  :  Cost  of  development  paid  for  in 
whole  by  Government,  or  development  was  required  for  performance  of  a 
Government  contract  or  subcontract; 

(b)  Developed  Exclusively  at  Private  Expense:  No  part  of  development  cost  paid  for 
by  Government  (IR&D  is  considered  private  expense),  and  development  not 
required  for  performance  of  a  Government  contract  or  subcontract;  and 

(c)  Mixed  Funding:  Combination  of  Government  and  private  funds. 

We  can  see  that  the  definitions  of  funding  include  not  only  the  sources  of  funds  but  also  the 
assessment  of  whether  the  item  (software)  was  required  for  performance.  While  DFARS 
227.472-3  addresses  itself  only  to  technical  data,  there  is  no  other  mixed  funding  reference  in 
DFARS,  Pan  227.  Clearly,  the  documentation  relating  to  software  would  fall  under  the 
subsection,  even  if  software  itself  did  not  The  FAR  provides  no  similar  definition  coverage  for 
development  at  Government  or  private  expense.  FAR  27.498  does  address  co-sp>onsored  research 
and  development  activities,  specifically  computer  software  and  appropriate  applications  of  limited 
rights  for  data  and  restricted  rights  for  software.  The  FAR  coverage  here  is  clearer  and  more 
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useful  than  that  provided  by  the  DFARS.  Even  though  the  FAR  provides  no  specific  definitions 
for  Government  or  private  funding,  its  definitions  of  unlimited,  limited,  and  restricted  rights 
clearly  employ  the  concept  of  private  expense,  and  do  not  mix  sources  of  funds  and  vagaries  of 
performance  in  the  definitions  of  funding  at  public  or  private  expense. 

3.1^.3  Software  Ownership  Policies  (See  Table  3-1) 

DFARS  227.481  establishes  the  policy  for  Government  acquisition  of  rights  to  computer  software, 
while  DFARS  227.472-3  addresses  rights  to  documentation  (technical  data)  related  to  the 
software.  This  Subpart  describes  those  circumstances  under  which  the  Government  gains 
unlimited  rights  to  software.  These  instances  include: 

(a)  Computer  software  resulting  directiy  from  performance  or  generated  as  pan  of  the 
performance  of  experimental,  developmental  or  research  work  specified  as  an 
element  of  performance  in  a  Government  contract,  or  subcontract; 

(b)  Computer  software  required  to  be  originated  or  developed  under  a  Government 
contract,  or  generated  as  a  necessary  pan  of  performing  a  contract; 

(c)  Computer  databases,  prepared  under  a  Government  contract,  consisting  of  (i) 
information  supplied  by  the  Government;  (ii)  information  in  which  the  Government 
has  unlimited  rights;  or  (iii)  information  in  the  public  domain; 

(d)  Computer  software  prepared  or  required  to  be  delivered  under  a  Government 
contract  or  subcontract,  and  consisting  of  corrections  or  changes  to  Government- 
furnished  software;  and 

(e)  Computer  software  in  the  public  domain,  or  normally  furnished  by  a  contractor  or 
subcontractor  without  restriction. 

Any  documentation  related  to  unlimited  rights  software  would  also  be  expected  to  be  provided 
as  unlimited  rights  data. 

If  software  does  not  fall  into  one  of  the  five  categories  described  above,  it  must  necessarily  fall 
into  the  category  of  restricted  rights  software.  DFARS  227.481  includes  a  reference  to  the 
DFARS  227.471  definition  of  restricted  rights  (Table  3-1)  for  a  description  of  the  minimum  rights 
required  by  the  Government.  The  clause  in  DFARS  252.227-7013(c)  provides  some  further 
guidance  relating  to  specific  rights  issues,  for  the  most  part  repeating  what  we  have  just 
discussed.  Government  minimum  rights  under  the  category  of  restricted  rights  in  computer 
software  are; 

(a)  Use  of  the  software  for  the  computer  for  or  with  which  it  was  acquired,  including 
use  at  any  Government  facility  to  which  the  computer  may  be  transferred; 

(b)  Use  of  the  software  with  a  backup  computer  if  the  computer  for  which  or  with 
which  it  was  acquired  is  not  working; 
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(c)  Copying  the  software  for  safekeeping  or  backup; 

(d)  Modifying  or  combining  it  with  other  software  as  long  as  the  delivered  software 
portions  containing  restricted  rights  software  remain  subject  to  those  rights;  and 

(e)  Any  other  rights  not  inconsistent  with  (a)-{d)  above. 

3,12.4  Software  Ownership:  Acquisition  Scenarios  (See  Table  3-2) 

Perhaps  the  best  way  to  describe  the  current  software  acquisition  environment  in  terms  of 
practical  applications  is  to  specify  scenarios  for  software  acquisition,  and  to  identify  the  rights 
which  would  accrue  to  either  the  Government  or  the  contractor.  Table  3-2  describes  these 
scenarios.  This  information  indicates  that  the  Government  will  obtain  unlimited  (or  close  to 
unlimited  in  the  case  of  mixed  funding)  rights  in  software,  with  the  exceptions  of  commercial 
software  and  unpublished  software  in  existence  at  the  time  of  a  contract  award.  The  contractor 
will  retain  its  copyright  to  software,  unless  the  Government  has  invoked  the  Spjecial  Works 
clause.  Friction  exists  between  Government  and  industry  regarding  software  developed  at  private 
expense,  but  in  parallel  with  and  required  in  the  performance  of  a  Government  contract.  Many 
in  industry  believe  that  the  contractor  should  retain  rights  to  this  software,  since  the  decision  to 
invest  corporate  funds  is  often  based  on  the  opportunity  to  later  capture  a  technical  and/or 
monetary  advantage  or  increased  market  share.  Furthermore,  industry  would  argue  that  many 
Government  programs  would  not  be  affordable  if  the  contractor  did  not  invest;  therefore,  it 
should  not  be  penalized  for  doing  so.  Rather,  it  should  be  rewarded  and  allowed  to  retain  the 
software  rights.  However,  the  Government  counters  by  arguing  that  if  the  software  is  developed 
in  parallel  with  contract  performance,  and  is  required  to  meet  contractual  obligations,  the 
Government  must  obtain  unlimited  rights  since  the  software  is  an  essential  contract  element.  It 
is  not  popular  to  counter  such  an  argument,  especially  if  the  Government  contends  that 
contractors  may  make  the  unlimited  rights  software  dependent  upon  or  integral  to  the  privately- 
funded  software  developed  in  parallel,  and  cause  the  Government  software  to  be  critically 
dependent  on  it. 

A  rather  significant  difference  exists  between  FAR  and  DFARS  approaches  to  acquiring 
commercial  software  (Table  3-2).  The  FAR  describes  the  Government  minimum  rights  required 
in  commercial  software,  and  then  states  that  no  specific  FAR  clause  is  required  (although  one 
is  provided).  This  allows  commercial  software  acquisitions  to  be  unhampered  by  the  overly 
cumbersome  and  confusing  basic  Rights  in  Data  clause.  In  contrast,  the  DFARS  provides  no 
practical  guidance  (227.481-1(0),  and  requires  the  full,  basic  Rights  in  Technical  Data  and 
Computer  Software  clause  (252.227-7013)  be  included,  with  reference  to  the  specific  portion 
dealing  with  commercial  computer  software  (252.227-701 3(c)(l)(ii)).  While  the  subparagraph 
language  is  not  objectionable,  many  commercial  companies  will  not  do  business  with  DoD 
because  they  are  put  off  by  the  DoD  acquisition  personnel’s  insistence  on  incorporating  the  whole 
12-page  clause  (as  required)  in  contract  language.  The  companies  become  apprehensive  that  they 
may  be  somehow  subject  to  the  other,  more  threatening  and  pervasive  sections,  and  walk  away 
from  the  revenues  rather  than  risk  loss  of  their  rights.  We  do  not  understand  why  the  DoD  has 
never  adopted  the  simpler  and  more  straightforward  FAR  approach  for  use  in  the  DFARS. 
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Some  contractors  have  noted  that  rJiey’ve  experienced  problems  with  the  Government  claiming 
unlimited  rights  in  unpublished  software  which  existed  at  contract  award.  In  these  instances,  the 
contractors  have  proposed  use  of  the  unpublished  software  and  claimed  restricted  rights.  The 
Government  has  countered  that  it  should  receive  unlimited  rights  (without  providing 
compensation),  since  the  software  was  required  for  performance.  Industry  notes  to  date  that  the 
results  of  negotiations  on  this  issue  have  been  mixed.  Claims  are  sometimes  substantiated,  with 
industry  given  restricted  rights  or  receiving  compensation  when  unlimited  rights  were  provided 
to  the  Government.  All  such  claims  are  negotiated  on  a  case  by  case  basis.  There  is  no  uniform 
policy  governing  comjjensation  to  contractors  for  restricted  or  limited  rights  software.  The 
DFARS  does  not  clearly  describe  the  contractor’s  and  Government’s  rights  with  respect  to 
unpublished  software  existing  at  contract  award. 

Regarding  copyrights,  the  DFARS  and  FAR  are  clear  on  policy.  The  contractor  will  typically 
retain  its  copyright  to  software  developed  under  Government  contract.  The  Government  will  be 
granted  a  license  to  use  it  for  Government  purposes,  including  preparation  of  derivative  works 
(important  for  software  reuse,  to  be  discussed  later).  Strangely,  while  the  DFARS  copyright 
license  includes  the  right  to  distribute  copies  to  the  public,  the  FAR  does  not,  unless  what  is 
known  as  the  Special  Works  clause  is  used  (Table  3-1).  When  the  Special  Works  clause 
(DFARS  252.227-7020)  is  invoked,  the  Government  retains  ownership  and  control  (copyright) 
of  the  work.  However,  regarding  software,  it  is  difficult  to  ascertain  why  one  would  invoke 
Special  Works  based  on  the  guidance  for  its  use  found  in  DFARS  227.476.  This  guidance  talks 
about  production  of  audiovisual  works,  television  recordings,  recruiting  and  other  similar  work, 
but  says  nothing  about  acquisition  of  products  and  systems  associated  with  software. 

A  simple  discussion  of  why  copyrights  are  important  at  all  is  lacking  in  the  DFARS.  Those  who 
prepared  the  regulations  assumed  that  the  read-*  '  would  be  well  versed  in  copyrights  -  this  is 
typically  not  true.  FAR  27.404(f)(l)(i)  is  somewhat  better  (but  not  by  much)  in  describing  how 
contractors  are  normally  granted  copyrights  to  enhance  dissemination  of  information  produced 
at  Government  expense  (i.e.  commercialize). 

NASA  takes  a  very  different  approach  to  copyrighting  software.  In  NASA  FAR  supplement  18- 
27.4046,  the  specified  policy  states  that  a  contractor  may  not  establish  a  copyright  claim  to 
software  first  produced  in  performance  of  a  NASA  contract  without  the  contracting  officer’s 
prior,  written  permission.  The  regulation  requires  proactive  Government  team  involvement 
(including  patent  or  intellectual  property  counsel)  in  determining  whether  a  contractor  has  specific 
commercial  plans,  and  has  made  or  will  make  a  significant  financial  contribution  to  the 
development  or  maintenance  of  the  software.  If  these  conditions  exist,  the  contractor  may  then 
be  authorized  a  copyright.  This  regulatory  coverage  goes  well  beyond  the  DFARS  and  FAR  in 
establishing  the  purpose  of  copyrights.  It  also  takes  a  very  different  position  concerning  the 
granting  of  copyrights  (automatic,  in  most  cases,  in  the  DFARS  and  FAR;  a  deliberate  act  in  the 
case  of  NASA). 

3. 1.2.5  Software  Rights  Clauses 

We  have  noted  the  difficulty  that  arises  in  working  with  the  DFARS  because  of  the  synthesis  of 
technical  data  and  software  into  one  category,  and  the  poor  structuring  of  the  contents  of  DFARS, 
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Part  27.  This  difficulty  is  perhaps  best  exemplified  in  the  basic  Rights  In  Technical  Data  and 
Computer  Software  clause  (DFARS  252.227-7013),  which  begins  on  DFARS  page  252.227-8  and 
concludes  on  page  252.227-20  (12  pages),  with  five  more  pages  covering  alternatives  to  the 
clause.  The  clause  includes  technical  data,  software,  copyrights,  rights  in  software  and  technical 
data,  limitation  on  charges  for  data  and  computer  software,  acquisition  of  technical  data  and 
software  from  subcontractors,  notification  procedures  and  other  topics.  It  is  unreasonable  to 
expect  even  the  most  sophisticated  person,  knowledgeable  in  software,  to  be  comfortable  working 
with  such  a  cumbersome  structure.  It  becomes  increasingly  unrealistic  o  expect  Government 
acquisition  personnel,  most  of  whom  have  little  or  no  formal  training  in  software,  to  be  able  to 
become  proficient  in  this  area  when  forced  to  work  with  such  cumbersome  guidance. 

3.1,2.6  Disincentives  in  Software  Rights  Clauses 

The  Strategic  Defense  Initiative  Organization’s  Strategic  Defense  System  Computer  Working 
Group  Software  Reuse  Committee  (26)  has  noted  in  their  studies  that  industry  is  reluctant  to 
provide  new  software  technology  because  of  the  sweeping  rights  demanded  by  the  Government, 
and  concerns  regarding  loss  of  proprietary  information.  Similar  concerns  were  raised  in  the  Fall 
1990  DoD  STARS/Users  Workshop.  Much  of  this  anxiety  arises  from  the  perception  that  the 
DoD  will  always  try  to  insist  on  unlimited  rights,  whether  or  not  it  needs  them  or  is  even  entitled 
to  them. 

We  believe  much  of  this  "Govemment-must-have-it-all"  atmosphere  is  created  by  a  lack  of 
understanding  by  federal  acquisition  personnel  of  software  and  its  issues,  compounded  by 
existence  of  inadequate  guidance  (DFARS)  to  help  accomplish  effective  and  reasonable  software 
acquisition  practices.  The  Government  by  nature  is  a  conservative  consumer.  Its  personnel 
become  more  conservative  when  working  with  regulatory  material  that  is  confusing  and 
cumbersome.  The  easiest  approach  is  to  insist  on  unlimited  rights,  thereby  forcing  industry  into 
lengthy  and  expensive  negoriation/litigarion  to  prove  otherwise.  We  agree  that  the  language  in 
DFARS  which  prescribes  Government  unlimited  rights  for  software  required  in  performance  of 
the  contract  (even  though  not  paid  for  by  the  Government)  does  create  a  disincentive  to  industry. 
It  presents  a  potential  disadvantage  to  the  Government  by  encouraging  the  creation  of  an 
environment  in  which  industry  becomes  increasingly  reluctant  to  use  its  latest,  privately- 
developed  software  technology  in  Government  acquisitions.  We  will  comment  more  on  this  issue 
later  in  the  report  when  discussing  the  15  October  1990  advanced  notice  on  FAR,  Part  27. 

Perhaps  the  most  significant  impediment  to  improved  software  acquisition  in  existence  today  is 
the  apparent  lack  of  a  concerted  effort  to  provide  the  acquisition  work  force  with  adequate 
guidance  to  improve  their  understanding  of  this  critical  area. 

As  the  FAR  is  modified  and  the  DFARS  rewritten,  we  will  continue  our  investigation  for  any 
other  significant  issues  regarding  the  DoD  software  acquisition  environment. 
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3.U  Software  Reuse 

The  conceptual  framework  for  software  reuse  includes  at  least  two  models  : 

(a)  Reusing  software/software  components  across  similar  applications  (e.g.,  Air 
Defense  Systems),  and 

(b)  Reusing  software/software  components  across  dissimilar  applications  (e.g.,  taking 
software  from  a  business  management  system  and  reusing  it  in  a  command  and 
control  system). 

This  reusable  software  is  either  software  in  existence  today,  or  software  specifically  developed 
to  be  reusable  beyond  its  initial  application.  Our  current  experience  base  reflects,  very 
predominantly,  reuse  of  commercial  software  or  non-commercial  software  not  specifically 
developed  to  be  reusable.  The  actual  practice  of  reuse  typically  occurs  through  the  forces  of  the 
competitive  bidding  process  or  happenstance.  Of  the  non-commercial  software  that  is  reused, 
most  was  not  designed  or  designated  for  reuse.  The  table  below  identifies  current  software  reuse 
strategies: 


Software  Reuse  Strategies 


•  Reuse  of  actual  code  (as  is  or  modified) 

•  Reuse  of  software  specifications 

•  Reuse  of  software  architectures 

•  Reuse  of  domain  knowledge  bases 

•  Generation  of  software  through 
creation  of  reusable  templates 


Prior  to  discussing  current  reuse  techniques,  we  will  examine  reuse  in  the  context  of  the 
DFARS/FAR.  We  will  then  provide  the  results  of  our  survey  investigation,  discussing  reuse 
strategies,  their  degrees  of  success,  ongoing  efforts  to  improve  reuse,  liability  issues  and 
recommendations  for  additional  improvements. 

3.1.4  Software  Reuse  in  the  Current  Environment 

Clearly,  there  are  no  overwhelming  impediments  in  the  current  DFARS/FAR  preventing 
successful  reuse.  Strategies  are  being  implemented  today  (not  necessarily  to  the  point  where 
they’ve  reached  fhiition)  for  software  reuse  within  the  Government.  Industry  already  successfully 
practices  reuse  in  the  commercial  world.  As  noted,  we  will  discuss  these  experiences  and 
provide  observations  on  the  differences  in  degrees  of  difficulty  when  dealing  with  intra-  and 
inter-program/agency  software  reuse  and  intra-  and  inter-company  reuse. 

We  identified  several  issues  at  the  beginning  of  this  repon  affecting  reuse:  liability,  ownership 
and  incentives.  Each  is  discussed  in  the  following  paragraphs. 
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3.1.4.1  Liability 

People  within  and  outside  Government  immediately  raise  the  liability  specter  when  software  reuse 
is  discussed.  When  the  Government  provides  softwaxe/software  components,  what  responsibility 
does  it  assume?  What  wananty  does  it  offer  regarding  how  the  product  will  perform?  What  is 
the  Government’s  liability  if  the  furnished  products  fail  when  used  as  is,  or  if  a  derived  software 
product  fails? 

If  the  original  software  producer  has  warranted  the  product,  the  Government  may  be  able  to  pass 
that  warranty  on,  unless  its  application  is  restricted  to  the  original  contract  under  which  the 
software  was  produced.  However,  the  warranty,  at  best,  is  likely  to  only  cover  the  software  in 
a  specific  application,  and  remedies  are  not  likely  to  offer  more  than  repair  or  replacement  of  the 
software,  so  that  its  intended  operation  is  unimpaired.  Reusing  the  software  to  create  a  derivative 
work  would  typically  void  any  existing  warranty,  even  if  it  could  be  passed  to  another  contractor. 
Therefore,  if  the  software  is  used  as  is,  a  second  contractor  might  have  an  opportunity  to  seek 
assistance  under  the  warranty  (not  likely).  When  used  in  a  derived  work,  any  warranty  is 
probably  voided.  Can  the  Government  then  indemnify  a  contractor  when  it  is  provided  with 
Government  software?  We  would  suggest  that  the  question  need  not  even  be  asked.  A 
better/more  correct  question  is  "should  the  Government  offer  protection?"  and  if  it  doesn’t,  is  this 
a  disincentive  to  reuse? 

We  do  not  believe  the  Government  should  attempt  to  offer  liability  protection  when  making 
software/software  components  available  for  reuse.  It  is  not  a  practical  alternative,  and  would 
require  a  prohibitively  expensive  testing  and  administrative  organization.  Rather,  the  Government 
should  provide  as  complete  a  description  as  possible  of  the  software  (including  source  code  if 
rights  permit),  all  available  documentation  (including  service  reports)  and  identification  of  the 
original  producer.  Whether  reuse  is  voluntary  or  mandated  by  the  Government,  the  new 
contractor  would  have  sufficient  information  available  to  make  an  intelligent  technical  and 
business  decision  regarding  its  ability  to  reuse  the  product  and  confidence  in  its  quality.  When 
reuse  is  mandated,  the  parties  involved  can  construct  added  contract  language  to  protect  specific 
interests  if  contention  arises  during  performance  concerning  each  party’s  liability  should  contract 
requirements  not  be  met. 

We  also  note  that  commercial  software  is  used  (reused)  over  and  over  without  the  liability  issue 
ever  surfacing.  The  significant  proliferation  of  these  products  actually  creates  greater  business 
risks  than  the  limited-use  instances  for  Government  software. 

Is  the  liability  issue  a  disincentive?  It  certainly  is  in  those  instances  where  software  is  unproven, 
is  provided  with  little  or  no  documentation,  evidences  no  records  of  update  or  service,  or  is 
furnished  with  such  restrictive  licenses  that  it  becomes  impractical  to  consider  the  product  for 
reuse.  We  contend  that  these  circumstances  would  negate  the  viability  of  this  software  for  reuse 
from  the  stan,  so  the  liability  issue  would  become  superfluous.  Critics  will  argue  that  this 
position  ignores  the  real  world,  in  which  overzealous  or  inexperienced  Government  organizations 
will  force  reuse  even  in  this  environment.  While  rare  instances  of  this  nature  could  occur,  a 
prudent  contractor  can  and  should  refuse  to  participate  under  these  circumstances.  In  any  event, 
it  is  impractical  to  attempt  to  protect  against  this  "exception"  to  the  rule,  beyond  a  Government 
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commitment  to  adequately  train  acquisition  personnel. 

The  Government  must  also  recognize  the  need  to  provide  a  system  that  will  ensure  the 
independent  testing/examination  of  software  products  made  available  for  reuse. 

3.1.4^  Ownership 

Ownership  issues  with  respect  to  unlimited  and  restricted  rights  software  and  limited  rights  data 
(for  the  restricted  rights  software)  are  relatively  straightforward  when  applied  to  software  reuse. 
When  the  software  and  supporting  data  are  provided  with  unlimited  rights,  a  contractor  is  free 
to  reuse  without  being  concerned  about  protection  of  another  party’s  proprietary  interests.  When 
the  Government  makes  restricted  rights  software  available  under  its  license  to  another  contractor 
for  Government  purposes,  the  process  is  more  involved.  The  new  contractor  must  protect  and 
preserve  the  integrity  of  the  original  restricted  software  when  preparing  the  new  software  (derived 
work).  The  newly  created  software  would  then  have  unlimited  rights  features  for  those  portions 
funded  by  the  Government.  Should  a  contractor  obtain  the  software  from  a  library  and  privately 
fund  the  new  development  for  another  government  application,  it’s  conceivable  that  the  newly 
created  software  would  have  two  restrictions  -  the  original  software  producer’s  and  the  new 
producer’s.  The  levels  of  restriction  could  also  differ.  While  this  sounds  complicated,  it  isn’t 
difficult  to  construct.  It  is  more  difficult  to  manage,  though,  especially  if  further  derivative 
works  are  created  with  or  without  Government  funding.  (Note:  The  restricted  rights  license 
granted  to  the  Government  does  not  permit  creation  of  derivative  works  for  non-Govemment 
purposes.)  Another  variant  for  reuse  occurs  when  a  contractor  proposes  to  reuse  some  other 
party’s  legitimately  restricted  tights  software.  In  this  instance,  the  new  contractor  is  obligated 
to  provide  the  Government  with  at  least  a  restricted  rights  license  for  the  reuse  software 
(assuming  the  government  has  agreed  to  the  new  contractor  employing  the  existing  restricted 
rights  software).  Again,  the  potential  exists  for  two  differing  levels  of  restrictions  on  the 
resulting  software  package. 

There  are  other  variants  regarding  commercial  software,  but  they  result  in  essentially  the  same 
scenarios.  For  an  interesting  discussion  of  restricted  rights  in  commercial  v;  noncommercial 
software,  see  the  Carnegie  Mellon  University/Software  Engineering  Institute  Technical  Report, 
CMU/SEI-86-TR-2(6).  When  the  software  is  obtained  from  a  library,  the  administration,  upkeep 
and  management  of  the  software  and  products  is  critical  to  liability  and  continued  use.  When 
the  Government  mandates  use  of  the  software,  it  must  clearly  articulate  any  restrictions  and 
carefully  construct  the  resulting  language  describing  the  agreement  on  rights  to  the  new  software 
product. 

Of  course,  any  limited  rights  data  associated  with  the  restricted  rights  software  would  follow  the 
same  track  in  maintaining/adding  legends  protecting  the  originator’s  interests.  Disincentives  exist 
only  to  the  extent  that  a  contractor  or  Government  program  organization  believe  the  products 
limit  creativity,  inhibit  competition,  and/or  make  the  new  product  more  expensive.  We  would 
caution  against  mandating  (some  would  argue  that  reuse  should  never  be  mandated)  reuse  unless 
comprehensive  architecture  analysis  and  cost  estimates  have  been  performed,  and  all  alternative 
acquisition  strategics  have  been  examined  (for  both  unlimited  and  restricted  rights  software). 
This  simply  makes  good  business  sense  for  any  Government  acquisition,  and  is  certainly  not  a 
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precaution  unique  to  reuse.  Rather,  it  is  a  recognition  that  the  opportunity  for  succf'^sful  reuse 
is  enhanced  by  sound  planning.  We  believe  acquisition  planning  documents  (such  as  service 
regulations  for  acquisition  strategy  meetings  and  DoD-STD-2167A)  should  require  assessment 
of  existing  software  for  reuse  potential. 

The  copyright  is  the  second  part  of  the  ownership  equation,  and  perhaps  the  more  confusing  one. 
As  outlined  in  Table  3-1,  the  DEARS  and  FAR  automatically  allow  the  contractor  to  claim  a 
copyright,  even  when  the  Government  has  paid  for  development.  NASA’s  approach  is  the 
opposite,  requiring  an  active  determination.  Utilizing  the  Special  Works  clause,  though,  can 
require  that  ownership  be  retained  by  the  Government. 

Note:  Many  in  the  legal  community,  including  the  authors  of  Software  Engineering  Institute 
repons  CMU/SEI-86-TR- 1  (5)  and  TR-2(6),  argue  that  while  the  Government  can  seek  assignment 
of  copyright,  it  cannot  take  direct  ownership  rights.  This  is  due  to  a  conflict  with  section  105 
of  the  copyright  act  (17  USC  Sec  105)  which  prohibits  such  action.  This  is  a  fairly  esoteric  legal 
issue,  but  one  we  should  pursue  because  of  its  impact  on  reuse  of  software. 

A  contractor  can  retain  its  copyright  even  when  the  Government  has  obtained  unlimited  rights 
in  software  and  its  related  documentation.  TTie  copyright  is  granted  to  promote  commercialization. 
However,  copyrights  have  significant  potential  implications  which  may  impact  incentives  to  reuse 
software.  One  example  involves  unlimited  rights  Government  software  in  a  simation  where  the 
development  contractor  has  claimed  a  copyright.  The  software  is  successfully  reused  by  another 
contractor  under  a  Government-funded  effort  Clearly,  the  Government  retains  full  unlimited 
rights  to  the  original  and  the  derived  software.  But  what  happens  to  the  copyright?  The 
Government  has  a  license  under  the  original  copyright  to  prepare,  or  have  prepared,  a  derivative 
work  for  Government  purposes,  but  can  the  new  contractor  claim  a  new  copyright?  Some  argue 
yes,  but  others  in  the  legal  community  argue  no.  The  only  clear  thing  is  that  the  issue  is  unclear. 
Significantly  more  research  on  this  issue  must  be  undertaken  with  the  intent  of  providing,  if 
possible,  an  unambiguous  interpretation  and  policy  statement.  If  a  contractor  cannot  claim  a 
copyright  when  creating  a  derivative  work,  a  certain  degree  of  incentive  to  reuse  is  necessarily 
lost  because  of  the  unrealized  potential  for  commercialization. 

We  could  construct  other  scenarios  for  restricted  rights  in  commercial  and  unpublished  software, 
but  the  scenarios  are  worse  than  those  described  above.  While  this  is  not  an  insurmountable 
issue,  we  must  conclude  that  it  currently  represents  an  impediment  in  those  instances  where  a 
contractor’s  motivation  is  principally  driven  by  success  in  the  commercial  market.  Beyond  this 
case,  we  see  no  preponderance  of  evidence  that  industry  has  spent  any  significant  time  on  the 
issues  of  derivative  works  and  copyrights.  As  reuse  becomes  more  prevalent,  we  are  sure  the 
issue  will  receive  much  more  anention.  When  the  Government  takes  assignment  of  copyright 
or  retains  ownership,  as  is  the  case  in  DFARS  Special  Works  (albeit  a  somewhat  controversial 
step,  assuming  a  DoD  person  even  figures  out  why  Special  Works  should  be  involved),  the  issue 
of  copyrighting  the  derived  software  is  less  convoluted.  Either  the  new  software  developer 
claims  a  copyright,  or  the  Government  continues  to  invoke  Special  Works,  retaining  ownership. 
When  the  new  contractor  retains  its  copyright  (we’re  assuming  unlimited  rights),  the  prior 
scenario  comes  into  play  when  future  derivatives  are  created.  When  the  Government  continues 
to  retain  ownership,  it  impedes  development  of  potential  commercial  markets,  so  the  contractor’s 
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incentive  to  participate  must  be  derived  from  some  other  source  (award  fees,  business  base, 
program  prestige,  etc).  We  should  point  out  that  success  in  the  commercial  market  is  not  solely 
linked  to  copyright  ownership,  but  also  to  other  issues  such  as  quality  of  training,  support  and 
packaging  of  the  software  product. 

We  have  only  briefly  captured  the  copyright  issue  here.  The  topic  is  extensively  treated  in  works 
by  Professor  Pamela  Samuelson,  Mr.  Kevin  Deasy  and  Mrs.  Anne  Martin  in  several  repons 
sponsored  by  DoD  through  the  Software  Engineering  Institute.  The  identification  of  these  works 
is  found  in  the  Bibliography  of  this  report.  While  we  may  not  agree  with  everything  they’ve 
concluded,  we  believe  future  work  in  the  copyright  arena  must  begin  with  an  analysis  of  these 
findings.  We  are  also  convinced  that  a  process  can  be  developed  to  satisfactorily  resolve  the 
copyright  issue  for  both  Government  and  commercial  software  reuse. 

Patents  are  a  third  ownership  issue.  Today,  we  see  an  increase  in  the  number  of  software  patent 
applications,  with  over  200  having  been  granted  in  the  last  two  years.  We  believe  that  the  issues 
related  to  software  copyrights  are  analogous  to  the  patent  rights  arena. 

3. 1.4.3  Incentives 

Many  business  advantages  motivate  contractors;  profitability,  sales  volume/market  share, 
technology  lead,  and  prestige/recognition  are  some  of  the  more  significant  motivators.  When 
planning  reuse  strategies,  one  must  consider  each  of  these  factors. 

3.1.4.3.1  Profitability 

Clearly,  the  opportunity  to  make  money  is  a  great  incentive.  Reuse  can  be  promoted  through 
classic  methods  such  as  royalty  payments  and  award  fees. 

In  the  royalty  arrangement,  a  contractor  would  be  paid  a  set  amount  every  time  its 
software/software  components  were  reused.  Even  if  the  Government  paid  for  the  software 
production,  the  royalty  would  be  an  added  incentive  to  the  contractor  to  use  its  best  resources 
to  assure  that  the  developed  software/softwarc  component(s)  and  related  documentation  were  of 
high  quality  and  would  continue  to  be  maintained  in  that  state.  The  disadvantage  of  the  royalty 
(unless  it’s  a  lump-sum  payment  based  on  reasonable  anticipated  reuse  events)  is  that  the 
contractor  must  wait  and  wonder  whether  or  when  the  software  will  ever  be  reused.  The 
Government’s  disadvantage  lies  primarily  in  die  administration  of  the  royalty  payment(s). 
Funding  should  not  be  an  issue,  though.  The  program  gaining  benefit  from  reuse  saves  money 
and  can  afford  the  royalty  cost.  The  program  originally  sponsoring  development  of  reusable 
software  can,  however,  be  shortchanged,  since  it  bears  the  expense  without  apparent  benefit  This 
can  be  overcome  by  establishing  a  pool  of  money  to  a^  to  programs  promoting  reusable 
software,  or  by  some  type  of  reimbursement  to  the  original  sponsoring  program  in  addition  to 
the  royalty  payment  Clearly,  the  mechanics  are  workable.  The  motivation  of  both  parties  may 
be  lacking,  though,  because  of  the  administrative  burden  and  lag  time  in  payback.  Nonetheless, 
it  is  an  avenue  not  yet  thoroughly  examined  and  exploited  in  reuse  strategy.  It  is  successful, 
though,  in  the  commercial  world  in  the  form  of  licenses  for  products.  The  characteristics  of 
high-volume  use,  dependable  maintenance  and  continued  upgrade  have  to  be  captured  for  it  to 
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be  successful  in  DoD.  The  library/repository  concept  may  be  the  solution  or  at  least  some  reuse 
packages. 

Award  fees  arc  being  used  today  to  promote  and  reward  reuse  (we  will  examine  some  examples 
later).  While  somewhat  subjective  in  nature,  they  arc  easily  structured  and  create  very  litde 
administrative  burden  for  the  Government  and  industry.  They  can  also  be  structured  to  focus  on 
the  aspects  of  reuse  most  critical  to  the  individual  program  or  class  of  programs.  Currently,  the 
FAR  (as  required  by  public  law)  limits  potential  award  fees  to  15%  for  development  and  10% 
for  other  efforts  when  using  cost  reimbursement  type  contracts  (FAR  15.903(D)).  While  15% 
remains  reasonably  acceptable,  it  is  not  sufficient  to  drive  quality  development  of  reusable 
software.  Similarly,  when  preparing  derivative  works  under  a  cost  reimbursement  contract,  using 
other  than  development  funding,  10%  is  much  too  low.  In  today’s  environment,  it  may  be  wise 
to  consider  a  change  to  this  pan  of  the  FAR,  allowing  higher  award  fees  for  contracts  promoting 
development  of  reusable  software  assets,  or  requiring  reuse  of  software  assets.  We  recognize  that 
some  may  argue  award  fees  can  be  used  without  these  restrictions  when  coupled  with  fixed  price 
contracts.  However,  this  is  fine  only  for  those  instances  where  fixed  price  contracting  is 
appropriate.  We  would  argue  that  there  are  many  situations  where  fixed  price  contracting  is  not 
an  acceptable  business  arrangement  for  the  encouragement  of  reuse. 

Performance  incentives  (FAR  16.402-2)  arc  also  available,  but  we  have  not  found  any  evidentiary 
material  describing  their  use  in  reuse  strategies.  Some  work  could  be  done  to  explore  the 
viability  of  structuring  simple  incentives  to  improve  performance  through  reuse  of 
software/software  components.  We  emphasize  simple  because,  historically,  performance 
incentives  have  been  overly  complicated,  and  have  created  an  imbalance  with  other  contract 
incentives. 

3.1.4.3.2  Sales  Volume/Market  Share 

We  have  chosen  to  treat  these  together,  yet  recognizing  that  they  arc  not  identical  concepts.  A 
company’s  sales  volume  can  grow  without  a  corresponding  increase  in  maricet  share,  if  the  rest 
of  the  industry  is  growing  as  quickly.  A  company’s  market  share  can  fall,  even  with  increased 
sales  volume,  when  the  rest  of  the  industry  is  growing  faster.  The  happy  medium  is  increased 
sales  volume  with  improved  market  share  and,  of  course,  ever  increasing  profitability!  A 
company  will  be  further  motivated  to  reuse  when  the  belief  exists  that  there  is  also  a  potential 
to  improve  its  volume  and  share  positions,  as  well  as  gain  rewards  through  lower  risk  and/or 
improved  profitability  on  a  particular  contract  employing  reuse.  DoD  can  foster  that  concept  by 
zealously  assuring  that  maximum  software  and  data  rights  as  well  as  copyrights  pass  to  the 
contractor.  This  would  motivate  the  contractor  to  pursue  reuse  with  its  best  resources,  because 
if  it  is  successful,  there  exists  the  potential  for  more  DoD  and  commercial  business.  The 
copyrights  issue  is  most  readily  solved  by  not  invoking  today’s  Special  Works  clause  when  the 
contractor  demonstrates  a  commitment  to  commercialization.  However,  if  the  contractor  fails  to 
commercialize  a  product  within  a  specific  period  of  time  (minimum  of  5  years),  ownership  would 
rcven  to  the  Government.  The  proposed  advanced  notice  of  rule  making  (FAR,  Part  27) 
addresses  copyrighting  in  a  somewhat  different  manner.  However,  this  is  probably  at  least  12 
months  from  implementation,  and  reuse  can’t  wait.  A  simple  DoD  policy  statement  could  make 
this  happen  without  resorting  to  DFARS  changes.  Pursuit  of  improved  contractor  rights  in 
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software  and  related  documentation,  though,  is  more  difficult  Given  the  pending  revisions  on 
data  and  software  rights,  we  expect  that  the  best  to  be  hoped  for  is  a  class  deviation  which  would 
invoke  some  of  the  new  features  of  the  revised  FAR,  Pan  27. 

The  Government  should  also  initiate  effons  to  promote  and  market  reuse  of  Government-owned 
software. 

3.1.4.33  Technology  Lead 

This  is  a  critical  element  in  each  contractor’s  strategy  for  maintaining  and  improving  market 
share.  Today,  even  when  the  Government  funds  software  reuse  projects,  v» .  don’t  believe  it 
receives  the  best  technology  industry  has  to  offer,  because  industry  fears  it  will  lose  that  precious 
element  (its  technology  lead)  under  today’s  software  and  data  rights  policies.  The  Government 
contends  that  it  should  obtain  all  the  rights  when  it  pays  for  the  product;  one  should  recognize, 
however,  that  a  contractor  is  not  likely  to  provide  a  potentially  lucrative  commercial  solution  in 
a  Government  contract  if  it  fears  that  it  will  lose  its  rights  to  that  solution.  More  likely,  the 
contractor  will  offer  an  acceptable  alternative  solution  which  is  less  creative  and  probably  more 
costly  in  the  life  cycle  of  a  system.  The  crux  of  this  problem  is  that  commercial  software 
vendors  do  not  believe  a  sizeable  market  for  DoD-specific  software  exists,  and  thus  will  not 
participate  with  their  highest-quality  technology  for  fear  of  losing  their  competitive  market 
positions.  Additionally,  DoD  contractors  which  develop  the  DoD-specific  software  do  not  appear 
to  have  the  expertise  to  create  commercial  products,  and  thus  remain  inhibited  by  the  issues  we 
have  raised. 

3.1.4.3.4  Value  Engineering 

Our  research  has  uncovered  no  instance  in  which  Value  Engineering  (VE)  has  been  identified  as 
a  potential  incentive  for  promoting  reuse.  FAR  48.001  defines  VE  as  "...  an  organized  effort  to 
analyze  the  functions  of  systems,  equipment,  facilities,  services  and  supplies  for  the  purpose  of 
achieving  the  essential  functions  at  the  lowest  life  cycle  cost  consistent  with  required 
performance,  reliability,  quality  and  safety".  We  believe  reuse  appropriately  falls  in  these 
categories  as  an  effective  method  to  reduce  overall  system  life  cycle  costs,  while  improving 
system  quality  and  reliability  through  use  of  proven  software  products. 

The  Govenunent  may  choose  to  mandate  a  VE  program  (FAR  48.101  (b)(2))  on  a  particular 
contract.  This  would  require  that  the  contractor  devote  specific  efforts  to  VE,  and  that  the 
Government  fund  that  effort.  In  a  VE  reuse  program,  DoD  could  create  a  contract,  funding  and 
incentive  environment  in  one  act.  It  appears  to  represent  a  perfect  potential  vehicle  for 
motivating  reuse  through  funding  suppon  and  incentive  rewards.  Even  if  the  Government 
retained  software  rights,  the  contractor  could  earn  incentive  rewards  which,  incidentally,  would 
not  be  subject  to  the  limitations  described  in  3.1. 4.3.1  and  3.2.5  of  this  report 

We  recommend  that  this  avenue  be  explored  and  a  test  program  be  selected  to  enable 
implementation  of  the  concept. 
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3. 1.4.3^  Prestige/Recognition 

There  are  more  motivators  than  immediate  financial  rewards  to  incentivize  industry.  The 
Malcolm  Baldrige  Award  for  Quality  is  an  excellent  example.  Right  now.  General  Motor’s 
Cadillac  Division  is  buying  full-page  advertisements  in  newspapers  (e.g..  Wall  Street  Journal) 
announcing  its  designation  as  a  recipient  of  this  prestigious  award.  It  provides  instant  credibility 
to  Cadillac  as  a  quality  producer,  a  very  desirable  characteristic  when  selling  automobiles.  While 
near-term  sales  may  increase,  ve  expect  Cadillac  will  attempt  to  capitalize  on  the  award  to 
produce  strategic  changes  in  long-term  growth  through  attraction  of  new  customers  and  increased 
return  customer  sales.  The  DoD  could  sponsor  a  similar  award  for  reuse  with  the  Defense 
Advanced  Research  Projects  Agency  (DARPA)  as  the  selection  organization,  assisted  perhaps  by 
the  services  and  the  SEI.  The  award  would  recognize  initiatives  and/or  results  in  promoting 
successful  reuse.  Carried  further,  some  type  of  credit  could  be  conferred  on  the  recipient  and 
other  finalists  (to  a  lesser  degree)  in  DoD  competitions  (source  selection)  and  award  fee 
deliberations. 

Through  this  award,  recipients  in  industry  would  become  recognized  as  quality  software 
producers,  and  would  be  given  a  potential  edge  in  DoD  competitions.  Commercial  postures 
would  undoubtedly  be  enhanced  by  receipt  of  the  award.  In  the  beginning,  DARPA  could 
present  the  award  annually  to  assure  its  effectiveness  as  an  incentive,  while  always  emphasizing 
that  awards  would  be  made  only  when  an  acceptable  finalist  is  presented.  At  some  point,  in  a 
year  of  lesser  candidates,  the  award  might  not  be  given  to  help  reinforce  its  importance.  We 
believe  that  this  concept  represents  a  significant  incentive,  and  strongly  urge  its  favorable 
consideration.  Refinements  could  be  pursued  once  its  utility  is  accepted.  Another  point  in  its 
favor  is  that  no  regulatory  changes  are  needed  in  the  DFARS  to  accommodate  the  notion  of  its 
use  in  source  selections,  award  fees  or  even  non-competitive  profit  negotiations  (it  would  be 
treated  as  a  special  factor  under  weighted  guidelines  (DFARS  215.902)).  A  simple  DARPA 
regulation  would  be  needed,  as  well  as  concurrence  from  the  other  potential  board  members  in 
order  to  ensure  their  participation.  We  expect  that  all  would  be  eager  to  serve.  Senior  personnel 
from  Government,  industry  and  academia  should  also  be  considered  for  involvement. 

The  current  DFARS/FAR  certainly  do  not  prevent  reuse.  However,  they  do  impede  its  practice 
because  of  the  psychological  business  barriers  believed  to  exist.  Contractors  today  are  reluctant 
to  practice  reuse  because  they  believe  it  will  weaken  them  competitively  if  they  are  forced  to 
share  trade  secrets  and  technology,  with  resulting  loss  of  favorable  competitive  posture  and 
ultimately  loss  of  market  share.  Perhaps  it  is  time  to  reexamine  the  intent  of  the  Competition  in 
Contracting  Act  regarding  the  basis  for  other  than  full  and  open  competition. 

3.1.4.4  Implications  of  DFARS  52.235-7002,  Recovery  of  Nonrecurring  Costs  on 
Commercial  Sales 

This  clause  requires  contractor  payback  of  Government  development  dollars  which  were  used  to 
provide  contract  support  for  development  of  an  item.  The  clause  requires  payback  when  a 
contractor  "intends"  to  enter  commercial  sales  for  the  item  or  essentially  similar  items.  It  is 
currently  an  Interim  DFARS  Rule,  signifying  that  the  Government  has  accepted  and  is 
considering  industry  comment  prior  to  implementing  the  clause  as  a  Final  Rule  (permanent 
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DFARS  coverage). 

Industry  is  strenuously  objecting  to  this  coverage.  NSIA  has  sponsored  efforts  to  have  this  clause 
reworked  or  revoked.  Apparently,  the  interpretation  of  the  clause  language  has  been  that  as  little 
as  10%  commonality  is  "essentially  similar".  Furthermore,  Government  investment  has  been 
interpreted  as  not  just  contract  dollars  but  also  IR&D  and  other  factors.  Finally,  industry 
contends  that  the  clause  does  not  cap  recovery  and  allows  excess  (and  excessive)  cost  recovery. 

There  are  implications  to  incentives  for  software  reuse.  If  a  contractor  believes  its  motivation 
to  commercialize  is  weakened  by  the  clause,  even  the  granting  of  a  copyright  to  the  contractor 
may  not  be  sufficient  to  support  commercialization  and  reuse  objectives.  The  contractor  will  not 
pursue  investment  in  reusable  software  if  it  believes  that  the  Government  can  recover  in  excess 
of  its  legitimate  development  investment. 

The  contractor  may  also  be  reluctant  to  reuse  other  Government- sponsored  software  if  it  believes 
it  may  be  subjected  once  again  to  this  clause  if  it  produces  derivative  software  (a  feasible 
scenario). 

We  support  the  NSIA  efforts  in  urging  the  Government  to  restructure  or  rescind  the  clause,  and 
will  pursue  our  own  further  investigation  of  this  subject  for  its  impact  on  reuse. 

3.1,5  Today’s  Reuse  Strategies 

We  have  found  a  number  of  examples  of  successful  reuse  strategies  and  others  that  are  in  the 
process  of  implementation.  These  are  summarized  in  Tables  3-3  through  3-7  and  detailed  in  the 
following  sections. 

Code  Reuse  (See  Table  3-3) 

This  is  perhaps  the  classic  example  of  reuse.  Here,  code  is  taken  from  one  application  and 
reused  "as-is"  or  modified  in  some  way  for  use  in  another  application.  The  new  application  may 
be  similar  or  completely  different  from  the  original. 

The  Foxboro  Company  specializes  in  process  control.  It  typically  will  perform  systems 
engineering  for  an  application,  then  design,  install,  test  and  maintain  a  sys,jm.  It  claims  80% 
code  reuse  in  its  work.  We  accept  this  claim  since  the  applications  are  very  similar  in  nature. 
Foxboro  licenses  its  commercial  software  packages  to  companies  designing  their  own  systems. 
However,  it  only  warrants  applications  when  it  has  designed  and  installed  the  system. 

The  EVB  Company  licenses  a  group  of  software  components  that  have  common  applications. 
They  do  not  anempt  to  claim  any  copyright  on  derivative  works  beyond  the  original  works 
copyright  if  their  prcxiuct  remains  intact.  Their  marketing  strategy  appears  to  focus  on  broad 
dissemination  of  their  product  base. 

The  Army  Tactical  Command  and  Control  System  (ATCCS)  has  mandated  reuse  by  contractors 
participating  in  the  program.  They  are  requiring  use  of  contractors’  software  across  multiple 


17 


30  March  1991 


STARS-SC-03501AX)1AX) 

STARS-SC-03504AX)1^ 


program  segments.  Reuse  is  experienced  both  at  the  code  and  specification  level.  The 
Government  has  funded  all  the  development  to  the  best  of  our  knowledge.  We  were  not  told  of 
any  unresolved  issues  concerning  software  rights  or  copyrights.  We  suspect  that  as  the  program 
matures,  additional  issues  will  surface.  ATCCS  appears  to  be  well  along  in  successful  reuse 
implementation.  It  definitely  warrants  continued  monitoring  to  assess  its  progress,  and  to  build 
case  study  materials  for  other  applications. 

The  Army’s  Advanced  Field  Artillery  Tactical  Data  System  (AFATDS)  has  been  promoting  reuse 
of  software  code.  Prior  to  initiating  any  new  software  development,  the  prime  contractor  is 
required  to  examine  other  code  (both  existing  in-house  or  from  other  programs)  for  possible 
reuse.  A  portion  of  the  contractor’s  award  fee  (10%  in  any  one  evaluation  period)  is  dependent 
upon  its  success  in  reusing  software.  We  have  no  status  on  the  program.  As  in  ATCCS,  the 
initiative  for  reuse  has  originated  within  the  Government. 

The  Air  Force’s  Automated  Weather  Distribution  System  (AWDS)  is  a  good  example  of  external 
code  reuse.  In  AWDS,  the  Air  Force  provided  code  "as  is"  from  its  development  program.  One 
competitor  used  the  code,  but  not  quite  "as  is".  The  firm  subcontracted  to  have  the  software  run 
through  a  translator  and  recreated  in  a  higher  order  language.  The  firm  was  one  of  three 
successful  competitors.  In  the  ultimate  production  competition,  the  firm  lost  but  not  because  of 
software.  This  is  an  excellent  example  of  reuse  not  being  mandated,  but  voluntarily  initiated  in 
a  competitive  environment.  There  were  no  liability  questions  raised.  The  firm  assessed  the 
software,  and  decided  that  it  was  fit  for  the  intended  purpose.  There  was  never  a  production 
deployment,  so  we  cannot  assess  what  would  have  happened  in  post-deployment  performance. 
We  aren’t  aware  of  any  copyright  issues.  AWDS  represents  another  good  example  for  case 
history  development. 

The  Air  Force’s  Command  Center  Processing  and  Display  System  Replacement  (CCPDSR) 
program  provides  another  reuse  variation.  TRW,  the  prime  contractor,  took  software  developed 
and  funded  under  the  CCPDSR  contract,  and  updated  and  reworked  the  product  using  internal 
funds,  with  the  intention  of  selling  it  commercially.  TRW  was  successful  and  has  since  licensed 
it,  under  the  acronym  UNAS  (Universal  Network  Architecture  Services),  to  both  Digital 
Equipment  Corporation  and  Rational.  Wc  haven’t  found  any  evidence  that  the  Government  has 
reused  the  original  software  product.  We  have  not  verified  this  point,  but  assume  that  TRW 
claimed  a  copyright,  allowing  it  to  commercialize  the  product.  Clearly,  this  reuse  occurred 
through  TRW’s  initiative,  and  has  been  commercially  successful.  Other  applications  which  may 
benefit  from  work  done  under  CCPDSR  include  ATCCS  and  the  Air  Force’s  Systems  Software 
and  Design  Center. 

AFATDS,  ATCCS,  UNAS  and  AWDS  demonstrate  sound  reuse  applications.  However,  they  also 
demonstrate  that  it  takes  Government  funding,  or  the  incentive  of  competition  or  the  commercial 
marketplace  to  make  it  work. 

3.1,5.2  Specification  Reuse  See  Table  3-4 

Conceptually,  reuse  at  the  specification  level  appears  to  be  very  promising.  As  we  described 
above,  ATCCS  is  mandating  reuse  at  this  level.  One  contractor  is  developing  common 
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specifications  for  use  by  ATCCS  segment  contractors.  Its  success  can  only  be  measured  by 
future  performance. 

Since  software  specifications  fall  under  the  definition  of  data  in  the  DFARS,  all  the  copyright 
issues  previously  described  don’t  apply.  Specifically,  an  originator  of  software  based  on  existing 
speciHcations  would  hold  the  first  copyright  claim.  There  would  be  no  derivative,  only  original 
software.  This  model  also  holds  promise  because  it  is  potentially  easier  to  understand  and  use. 
We  would  support  more  research  and  practical  applications  in  this  area. 

3.1,5.3  Top-Level  Software  Architecture  Reuse  (See  Table  3-5) 

Once  again,  we  found  a  great  deal  of  conceptual  discussion.  The  Air  Force’s  Granite  Sentry 
Program  managed  by  the  Electronic  Systems  Division  is  one  example  of  this  type  of  reuse.  The 
model  envisions  architectures  that  are  generic  in  nature,  which  could  be  used  over  and  over  again 
across  a  variety  of  applications.  The  benefit  is  in  saving  the  time  and  money  typically  involved 
in  higher-level  analyses.  Presumably,  there  would  be  a  corresponding  risk  reduction  because  the 
architecture  would  be  proven.  We  accept  and  support  the  concept  However,  it  requires  further 
development  to  produce  results. 

3.1^.4  Domain  Knowledge  Base  Reuse  (See  Table  3-6) 

This  model  approaches  software  reuse  from  the  perspective  of  analyzing  existing  software.  This 
analysis  is  coupled  with  knowledge  of  a  relevant  technology  base,  as  well  as  the  theory  and 
expertise  developed  in  a  particular  domain  (command  and  control,  for  example),  which  results 
in  an  engineering  solution  in  which  software  and  related  documentation  are  reused.  The  model 
takes  the  more  haphazard/  serendipitous  code  reuse  scenarios,  and  applies  a  systems  engineering 
perspective  to  the  concept  of  reuse.  Its  appeal  results  from  the  potential  to  realize  not  only  a 
well-engineered  solution  involving  software  reuse,  but  also  the  construction  of  a  permanent  base 
of  engineering  knowledge  through  systematic  examination  of  the  particular  domain.  In  turn,  the 
model  creates  a  resource  for  potentially  unlimited  future  applications. 

The  DoD’s  Software  Engineering  Institute  is  currently  performing  research  in  this  area.  It  has 
supported  the  ATCCS  program  in  developing  reuse  strategies.  The  Joint  Integrated  Aviotucs 
Working  Group  (JIAWG)  is  also  examining  potential  programs,  including  the  F-18  and  the 
Advanced  Tactical  Fighter,  as  candidates  for  domain  knowledge  base  applications.  In  addition, 
the  Strategic  Defense  Initiative  Organization/National  Test  Bed  Joint  Program  Office 
(SDIO/NTBJPO)  and  the  Navy’s  Naval  Research  Laboratories’  (NRL)  Command,  Control, 
Communications  and  Intelligence  (C*I)  efforts  are  being  examined  for  their  appropriateness  for 
potential  involvement. 

3.1.5.5  Generation  of  Software  (See  Table  3-7) 

This  is,  perhaps,  the  most  radical  of  all  current  software  reuse  strategies.  It  has  been 
implemented  on  the  recently  awarded  (August/September  1990)  Flight  Simulator  program  at  the 
Air  Force’s  Aeronautical  Systems  Division  with  the  help  of  the  DoD  SEI. 
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This  model  promotes  use  of  templates  to  reengineer  software.  The  templates  capture  elements 
common  to  particular  applications.  The  elements  are  described  in  the  template  in  a  way  which 
enables  specific  applications  to  merely  identify  their  peculiar  performance  requirements  for  those 
template  elements.  Once  the  templates  are  created  and  the  performance  requirements  identified, 
the  software  generation  process  is  a  routine  event  There  is  no  need  to  reuse  the  code,  because 
the  template  is  infinitely  reusable  within  the  application  field.  The  concept,  similar  to 
specification  and  architecture  models,  obviates  some  of  the  reuse  issues  we’ve  described.  Its 
challenge  lies  in  being  able  to  construct  a  systematic  engineering  process  which  will  consistently 
produce  viable,  workable  templates.  Our  research  to  date  suggests  that  a  structure  which  would 
enable  the  process  to  be  repeated  for  dissimilar  applications  does  not  exist. 

The  most  notable  aspect  of  today’s  reuse  strategies  is  their  common  goal  of  eliminating  the 
constant  production  of  new  software  assets.  The  potential  for  risk  reduction,  schedule 
acceleration,  improvement  in  quality  and  money  savings  is  astounding.  The  next  most  notable 
aspect  of  the  current  reuse  environment  is  the  lack  of  a  focused  effon  (within  DoD,  prior  to 
STARS)  to  capture  and  promote  reuse  as  a  discipline.  While  reuse  technology  is  currendy  being 
promoted,  the  business  environment  has  a  lot  of  catching  up  to  do.  Our  examination  of  the 
current  strategies,  the  DFARS  and  FAR  and  research  on  available  techniques,  has  convinced  us 
that  the  focus  on  business  considerations  must  match  the  technology  efforts  to  ensure  that  reuse 
becomes  a  viable,  accepted  technology.  Much  of  that  can  be  accomplished  through  new  products 
for  educating  and  training  Government  acquisition  personnel  in  effective  reuse  strategics.  Persons 
in  all  disciplines  must  eventually  be  educated,  but  efforts  must  first  be  targeted  toward  those 
penons  in  a  position  to  effect  the  greatest  change,  namely  program  managers,  contracting 
officers,  logisticians  and  legal  personnel. 

3.1.6  Analysis  of  Advanced  Notice  of  Rulemaking  for  FAR,  Part  27  and  Proposed 
Changes 

As  noted  previously,  the  proposed  regulatory  change  to  the  Federal  Acquisition  Regulation 
(FAR):  Rights  in  Technical  Data  -  Advanced  Notice  of  Proposed  Rulemaking,  Federal  Register, 
Vol.  55,  No.  199,  15  October  1990  proposes  to  replace  the  current  DFARS  227.4  (Interim  Rule, 
1988)  and  FAR  27.4  with  a  single  regulation  for  all  Government  agencies  addressing  rights  in 
technical  data  and  computer  software.  We  attended  the  November  19,  1990  and  January  11, 
1991  public  hearings  on  this  advanced  notice. 

By  presenting  the  regulatory  change  as  an  advanced  notice,  the  Government  has  essentially 
acknowledged  the  potential  for  extensive  comment  and  subsequent  rewrite  prior  to  publishing  the 
change  as  an  Interim  Rule.  While  comments  are  accepted  on  Interim  Rules,  historically  the  final 
product  has  been  essentially  the  same  as  the  published  Interim  Rule.  The  FAR  Council  has  not 
provided  a  timeline  for  publishing  an  Interim  Rule;  however,  we  anticipate  that  it  will  be 
published  at  least  12  months  from  the  October  1990  Federal  Register  Notice. 

There  are  some  significant  changes  in  the  advanced  notice.  We  will  address  these  changes  in 
general  terms  now,  and  later,  as  an  update  to  this  rcpon,  we  will  provide  more  detailed 
comments.  We  will  continue  to  focus  on  the  impact  these  changes  will  have  on  software  reuse, 
and  any  other  proposed  modifications. 
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In  combining  DFARS  227.4  and  FAR  27.4,  the  Federal  Government  has  taken  a  giant  step 
forward.  Now,  a  single  regulation  will  exist  which  addresses  the  Government’s  and  contractor’s 
rights  regarding  data  and  software.  We  thus  immediately  eliminate  present  inconsistencies  (Table 
3-1)  between  the  documents.  However,  the  controversies  are  not  totally  eliminated.  In  the 
following  sections,  we  will  review  the  more  important  issues,  commenting  on  whether  any 
improvements  have  occurred  with  respect  to  reuse. 

3.1.6.1  Data  and  Software  Continue  to  be  Treated  Together 

During  the  19  November  1990  public  hearing,  the  Government  stated  that  its  decision  to  maintain 
combined  coverage  resulted  from  the  conclusion  that  there  were  more  similarities  than  differences 
in  the  topics.  However,  we  continue  to  maintain  that  the  existence  of  differences  provides 
sufficient  justification  to  separate  treatment  of  software  and  data.  Continuing  to  combine  the 
topics  unnecessarily  complicates  and  confuses  issues.  As  an  example.  Subpart  27.4  continues  to 
be  titled  Rights  in  Data  and  Copyrights  with  no  mention  of  software.  Additionally,  sections 
27.402,  403  and  404  either  initially  address  only  data  or  only  include  "Data"  in  the  title  of  the 
section.  Finally,  the  phjase  "developed  and  necessary"  for  performance  is  replacing  the 
controversial  term  "requited  for  performance".  When  the  phrase  is  used  in  27.404-1  (a)(l)(i)(B), 
it  initially  refers  to  data  and  software,  but  then  reverts  only  to  use  of  the  term  "data".  When  the 
phrase  is  used  in  52.227-14,  subparagraph  (b)(l)(i)(B),  the  terms  software  and  data  are  only  used 
once,  and  do  not  create  the  potential  confusion  of  whether  the  Government  intentionally  or 
unintentionally  omitted  software  in  the  second  reference  in  27.404-l(a)(l)(i)(B).  These  examples 
reinforce  our  belief  that  as  long  as  the  topics  are  addressed  together,  software  will  not  receive 
proper  treatment.  The  FAR  authors  continue  to  create  confusion  due  to  their  lack  of 
understanding  of  software  and  its  significance.  A  higher  degree  of  sophistication  regarding  how 
software  must  be  viewed,  with  respect  to  Government  rights  and  industry  intellectual  property 
interests  is  required.  Additionally,  a  more  focused  discussion  of  critical  software  issues,  provided 
in  a  more  readable  style  is  still  necessary. 

3.1.6.2  Introduction  of  Government  Purpose  Rights  (GPR) 

The  NASA  approach  to  encouraging  commercialization  has  been  adopted  in  GPR.  Under  these 
circumstances,  the  contractor  is  allowed  to  retain  exclusive  commercial  rights  for  a  negotiated 
period  of  time,  after  which  the  software  or  data  reverts  to  unlimited  rights.  The  significance  of 
this  approach  is  that  the  contractor  is  provided  with  commercial  protection  in  both  mixed  funding 
and  100%  Government  funding  situations  when  it  can  demonstrate  an  intention  to  commercialize 
-  a  very  different  and  progressive  change  from  the  current  DFARS.  Under  GPR,  the  Government 
obtains  a  license  for  use  and  disclosure  relating  to  Government  purposes,  providing  the 
contractor’s  limited,  exclusive  commercial  rights  are  protected.  Is  the  coverage  better?  Yes.  Is 
it  as  good  as  it  could  be?  No. 

The  DAR  Council’s  Deputy  Director,  Ms.  Linda  Greene  is  quoted  in  the  15  October  1990  issue 
of  the  Federal  Contracts  Report  (Vol.  54,  No.  15,  page  549)  as  saying  "The  draft  rule  also 
establishes  more  of  a  preference  for  Government  purpose  rights  [than  unlimited  rights]  than  is 
present  under  the  [1988]  Interim  Rule.  We  think  we’ve  made  a  gigantic  stride  there." 
Unfortunately,  while  the  coverage  has  improved,  the  advanced  notice  does  not  emphasize  GPR 


21 


30  March  1991 


STARS-SC-03501/001/a) 

STARS-SC-03504AX)l/00 


over  unlimited  rights.  Examining  Subpart  27.404-1,  unlimited  rights,  and  27.404-4,  GPR, 
reveals  that  the  Government’s  stated  policy  is  still  to  acquire  unlimited  rights  unless  the  contract 
specifies  GPR  or  copyrights.  So,  while  intentions  are  good,  policy  statements  do  not  promote 
commercialization  objectives  found  in  GPR  over  obtaining  unlimited  rights.  Unless  27.404- 1  is 
changed  to  explicitly  favor  GPR  over  unlimited  rights.  Government  acquisition  personnel  will 
continue  to  pursue  fiiii  rights  and  pro’-nde  disincentives  to  industry  to  invest  (mixed  funding)  or 
participate  at  all.  Software  reuse  is  not  incentivized  by  the  advanced  nodce  policy  language, 
even  though  GPR  has  provided  a  vehicle  to  protect  commercial  rights.  The  positive  policy 
statements  in  Subpart  27.402  are  negated  by  the  ineffective  implementation  guidance  in  27.404. 

3. 1.6.3  Copyrights 

The  FAR  approach,  which  is  more  favorable  to  industry  regarding  commercial  exclusivity  (Table 
3-1),  has  been  adopted  in  the  advanced  notice.  The  Government’s  copyright  for  software  does 
not  include  the  right  to  distribute  copies  to  the  public  as  is  now  found  in  DFARS.  This  should 
help  promote  reuse,  since  a  contractor  will  now  be  assured  that  its  full  commercial  rights  are 
protected.  A  more  proactive  Government  approach  (similar  again  to  NASA)  has  been  taken 
regarding  the  decision  process  governing  the  granting  of  contractors’  copyrights.  The  coverage 
has  also  been  improved  by  providing  a  more  complete  explanation  of  why  copyrights  are 
important  (commercialization).  However,  copyrights,  like  unlimited  rights  and  GPR,  do  allow  full 
disclosure  for  Government  purposes.  Therefore,  the  contractor’s  incentive  to  partially  fund 
creation  of  reusable  software,  or  to  put  its  best  talent  on  totally  Government-funded  software 
projects  remains  inhibited,  since  the  current  structure  doesn’t  enable  the  contractor  to  benefit 
from  Government-sponsored  reuse  of  its  products. 

The  issues  we’ve  identified  regarding  the  copyrighting  of  derivative  works  are  not  dispelled  by 
the  advanced  notice  coverage  in  Subpart  27.404-5  and  its  associated  clauses. 

The  issue  concerning  use  of  the  current  DFARS  Special  Works  clause  is  now  covered  in  Subpart 
27.406  and  its  associated  clause  in  52.227-17.  We  see  no  appreciable  change  beyond  a  statement 
regarding  inapplicability  to  "Limited  Rights  Data  or  Restricted  Rights  -  Software".  This  reference 
is  not  clear,  and  we  maintain  that  copyright  issues  under  27.406  will  continue  to  impact  the  DoD 
contractor  community. 

3.1.6.4  Commercial  Software 

Subpart  27.406(c)  does  incorporate  the  FAR  approach  to  defining  commercial  software  and 
providing  more  appropriate  clause  coverage  (52.227-19).  Unfortunately,  it  also  allows 
Government  personnel  to  revert  to  the  basic  Rights  in  Data  clause  by  itself  or  in  concert  with 
52.227-19.  We  expect  the  conservative  acquisition  professional  will  do  just  that,  and  continue 
to  create  unnecessary  confusion  and  contention  with  commercial  software  vendors.  The  guidance 
also  negatively  impacts  commercial  software  licenses  by  noting  that  the  intent  of  52.227-19  is 
to  supersede  any  portions  of  those  licenses  that  are  inconsistent  with  Government  restricted  rights 
needs.  This  should  be  changed  to  state  that  a  commercial  software  license  will  always  be 
acceptable,  unless  it  can  be  factually  demonstrated  to  be  inconsistent  with  the  Government’s 
minimum  needs  as  found  in  the  restricted  rights  definition.  Without  this  type  of  change. 
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commercial  vendors,  especially  the  small  and  innovative  ones,  will  continue  to  avoid  Government 
business  because  they  will  perceive  the  Government  as  an  unfriendly  and  threatening  Qoss  of 
proprietary  interests)  customer.  Once  again,  the  opponunity  for  reuse  enhancement  is  potentially 
lessened  by  what  will  be  perceived  as  a  negative  approach. 

On  balance,  the  revised  coverage  of  the  FAR  is  superior  to  that  currently  found  in  the  DFARS. 

3.1.6.5  Mixed  Funding 

We  noted  that  the  DFARS  only  addresses  mixed  funding  in  the  context  of  technical  data. 
Subpart  27.402(c)  of  the  advanced  notice  corrects  this  situation,  also  addressing  computer 
software.  It  clearly  directs  the  Government  to  consider  not  only  shared  funding,  but  also  its 
ultimate  requirements  before  determining  appropriate  rights  to  be  acquired.  It  further  directs  the 
rights  issue  to  be  addressed  at  the  lowest  possible  level  of  software  identification.  This  should 
help  focus  issues  on  particular  modules  or  components  and  narrow  contentious  areas.  We  believe 
Subpart  27.404  should  contain  a  reference  back  to  27.402  to  assure  that  rights  issues  will  be 
properly  considered  where  mixed  funding  occurs,  and  that  GPR  will  be  stated  as  the  most 
stringent  Government  rights  possible  under  such  a  scenario.  Furthermore,  the  contractor  should 
always  be  allowed  to  claim  a  copyright  in  mixed-funding  situations. 

3.1.6.6  "Required  for  Performance" 

This  term  has  been  deleted.  The  advanced  notice  now  makes  reference  to  the  concept  of 
"developed  and  necessary"  for  performance  (52.227- 14(b)(l)(i)(B))  when  identifying  simations 
in  which  the  Government  must  obtain  unlimited  rights.  The  advanced  notice  states  a  belief  that 
this  change  has  narrowed  the  application  of  the  concept,  but  we  do  not  agree.  We  sec  no  change 
of  any  significance  in  the  new  52.227-14  (b)(l)(i)(B),  when  compared  to  DFARS  227.471  and 
252.227-7013  language.  Since  the  advanced  notice  gives  no  further  explanation  or  example  to 
clarify  how  this  "narrowing"  has  occurred,  we  suspect  there  is  more  show  than  substance  in  the 
claim.  Another  concern  of  even  greater  importance  is  the  fact  that  the  offensive  DFARS 
language  is  now  proposed  for  use  throughout  the  Federal  Government.  Without  deletion  or 
radical  modification,  all  federal  agencies  will  now  face  the  same  contention  existing  today 
between  industry  and  the  DoD. 

This  "required  for  performance"  issue  continues  to  be  the  most  significant  potential  impediment 
to  software  reuse.  Industry  will  not  provide  its  own  products  or  use  its  best  talent  when  faced 
with  loss  of  its  competitive  position  within  the  commercial  and  Government  markets.  While  the 
Government  can  foster  reuse  through  its  own  funding  for  new  software,  it  continues  to  lose 
potential  reuse  opportunities  derived  from  use  of  induscy-funded  software. 

The  concept  should  be  changed  to  allow  for  more  favorable  industry  treatment  A  change  in 
wording  which  would  allow  contractors  to  retain  rights  for  the  duration  of  the  contract  (or  a 
minimum  of  5  years)  might  be  sufficient  to  overcome  this  impediment.  We  will  continue  to 
explore  this  potential  solution. 
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3. 1.6.7  Conclusion 

We  have  addressed  the  most  significant  potendal  changes  for  software  reuse  in  the  advanced 
nonce  of  rulemaking.  Overall,  it  is  a  more  understandable  treatment  of  rights  in  data  and 
software,  though  the  basic  Rights  in  Data  clause  remains  hoirific  in  its  length  and  treatment  of 
a  multimde  of  issues. 

We  prepared  specific  language  changes  which  were  submitted  to  the  FAR  Council  as  formal 
comment  on  the  advanced  notice  (Appendix  D).  The  Council  will  now  only  accept  comments 
on  the  advanced  notice.  Given  the  timing  of  the  advanced  notice,  the  DAR  Council  will  not 
consider  a  DAR  case  on  the  existing  DFARS. 

3.2  Findings  and  Recommendations 

The  following  findings  and  recommendations  are  based  on  the  concepts  and  ideas  expressed 
within  Section  3.1.  We  have  also  drawn  on  our  extensive  review  of  supporting  documentation 
(Appendix  C).  Our  attendance  at  Government  and  industry  briefings,  conferences  and  workshops, 
coupled  with  numerous  interviews  provided  us  with  an  invaluable  source  of  information  and 
innovative  ideas  (Appendix  B). 

3.2.1  Ease  of  Use 

3.2.1.1  Finding/Recommendation 

Today’s  DFARS  coverage  on  software  and  software  rights  is  not  well  written,  is  poorly  organized 
and  very  difficult  to  understand.  The  proposed  regulatory  change  replaces  the  current  DFARS 
227.4  (Interim  Rule,  1988)  and  FAR  27.4  with  a  single  regulation  for  all  Government  agencies, 
addressing  rights  in  technical  data  and  computer  software.  The  proposed  FAR,  Pan  27  is  an 
improvement,  but  still  does  not  properly  segregate  and  focus  software. 

A  more  focused  discussion  of  critical  software  issues,  provided  in  a  more  readable  style  is  still 
necessary. 


3.2.1.2  Finding/Recommendation 

Neither  the  DFARS  nor  the  FAR  treat  software  separately  from  technical  data.  In  the  19 
November  1990  public  hearing  on  revised  FAR,  Pan  27,  the  Government  stated  that  its  decision 
to  maintain  combined  coverage  for  technical  data  and  software  resulted  firom  the  conclusion  that 
there  were  more  similarities  than  differences  in  the  topics. 

Separate  treatment  is  necessary  for  software  to  be  adequately  addressed.  We  continue  to  maintain 
that  the  existence  of  differences  provides  sufficient  justification  to  separate  treatment  of  software 
and  data.  Continuing  to  combine  the  topics  unnecessarily  complicates  and  confuses  issues. 
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3.2. 1.3  Finding/Recommendation 

The  DFARS  Rights  in  Technical  Data  and  Computer  Software  clause  starts  on  page  252.227 -S 
and  concludes  on  page  252.227-20  (12  pages).  It  is  unreasonable  to  expect  even  the  most 
sophisticated  person,  knowledgeable  in  software,  to  be  comfortable  working  with  such  a 
cumbersome  structure. 

A  new,  concise  clause  is  required  for  software.  It  should  be  easily  understood,  comparable  to 
what  the  insurance  industry  has  done  with  its  policies. 

3.2.2  Software  Rights 

3.2.2. 1  Finding/Recommendation 

Unpublished  software  becomes  Government-owned  software  if  it  is  created  during  and  required 
for  Government  contract  performance,  even  if  it  is  100%  funded  by  a  contractor.  This  is, 
perhaps,  the  most  contentious  issue  between  Government  and  industry  today  in  the  debate 
concerning  required  DFARS  changes.  The  language  in  DFARS  which  acquires  Government 
unlimited  rights  for  software  required  in  performance  of  the  contract  (even  though  not  paid  for 
by  the  Government)  does  create  a  disincentive  to  industry.  The  "required  for  performance" 
wording  has  been  replaced  with  "developed  and  necessary"  in  the  proposed  revision  to  FAR,  Part 
27.  The  introduction  to  the  revision  states  a  belief  that  this  change  has  narrowed  the  application 
of  the  concept. 

The  proposed  regulation  does  not  go  far  enough,  and  should  be  changed  to  allow  for  more 
favorable  industry  treatment.  A  change  in  wording  which  would  allow  contractors  to  retain  rights 
for  the  duration  of  the  contract  (or  a  minimum  of  5  years)  might  be  sufficient  to  overcome  this 
impediment.  The  concept  could  provide  for  an  escrow  provision  to  protect  the  Government’s 
interests  in  the  event  of  company  failure  or  lack  of  continued  product  support.  In  the  event  the 
contractor  did  not  commercialize  within  the  stated  period,  ownership  would  reven  to  the 
Government.  It  is  clear  that  a  better  solution  than  that  found  in  the  proposed  FAR,  Pan  27 
revision  is  required. 

2.12.2  Finding/Recommendation 

The  DFARS  (227.481-1(0)  provides  no  practical  guidance  for  acquiring  commercial  software. 
It  requires  that  the  full  Rights  in  Technical  Data  and  Computer  Software  clause  (252.227-7013) 
be  included.  The  specific  portion  dealing  with  commercial  computer  software  (252.227-7013, 
(c)(l)(ii))  is  the  only  portion  of  the  clause  that  is  actually  applicable  to  the  purchase  of 
commercial  software. 

We  do  not  understand  why  the  DoD  has  never  adopted  the  simpler  and  more  straightforward 
FAR  approach  for  use  in  the  DFARS.  However,  the  proposed  FAR,  Pan  27  revision  does  adopt 
the  FAR  approach  (see  next  finding). 
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3.2J.3  Finding/Recommendation 

The  revised  FAR,  Part  27,  Subpart  27.406(c)  does  incorporate  the  more  straightforward  FAR 
approach  to  defining  commercial  software  and  providing  more  appropriate  clause  coverage 
(52.227-19).  Unfortunately,  it  also  allows  Government  personnel  to  revert  to  the  basic  Rights 
in  Data  clause  by  itself  or  in  concert  with  52.227-19.  We  expect  the  conservative  acquisition 
professional  will  do  just  that,  and  continue  to  create  unnecessary  confusion  and  contention  with 
commercial  software  vendors. 

Subpart  27.406(c)  should  be  changed  to  state  that  a  commercial  software  license  will  always  be 
acceptable,  unless  it  can  be  factually  demonstrated  to  be  inconsistent  with  the  Government’s 
minimum  needs  as  specified  in  the  restricted  rights  definition. 

3.2,2.4  Finding/Recommendation 

The  DFARS  does  not  clearly  describe  the  contractor’s  and  Government’s  rights  with  respect  to 
unpublished  software  existing  at  contract  award. 

The  FAR,  Part  27  revision  should  be  altered  to  explicitly  state  that  existing,  unpublished  software 
is  restricted  rights  software  unless  the  Government  acquires  greater  rights  through  licensing  or 
acquisition. 

3.22.S  Finding/Recommendation 

When  reusing  restricted  rights  software,  the  contractor  must  protect  and  preserve  the  integrity  of 
the  restricted  software  when  preparing  the  new  software  (derived  work). 

More  guidance  is  required  for  acquisition  personnel  on  how  to  effectively  reuse  restricted  rights 
software.  The  guidance  should  include  methods  for  distinguishing  between  the  original  and 
derived  work.  The  proposed  handbook  (3.2.4)  could  address  this  subject 

3.2,2.6  Finding/Recommendation 

The  NASA  approach  to  encouraging  commercialization  has  been  adopted  through  the  GPR 
description  in  the  proposed  FAR,  Pan  27  revision.  Under  GPR,  the  Government  obtains  a  license 
for  use  and  disclosure  relating  to  Government  purposes,  providing  the  contractor’s  limited, 
exclusive  commercial  rights  are  protected.  Unfortunately,  while  tltis  change  improves  the 
coverage,  the  Part  27  revision  does  not  promote  GPR  over  unlimited  rights.  The  positive  policy 
statements  in  revised  FAR,  Part  27,  Subpart  27.402  are  negated  by  the  ineffective  implementation 
guidance  in  27.404. 

While  the  Government’s  intentions  are  good,  the  proposed  new  policy  statements  do  not 
encourage  commercialization  objectives  found  in  GPR  over  obtaining  unlimited  rights.  Unless 
27.404-1  is  changed  to  explicitly  favor  GPR  over  unlimited  rights.  Government  acquisition 
personnel  will  continue  to  pursue  full  rights,  and  provide  disincentives  to  industry  to  invest 
(mixed  funding)  or  participate  at  all.  We  recommend  that  27.404-1  be  changed  to  explicitly 
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favor  GPR  over  unlimited  rights. 

2.12.1  Finding/Recommendation 

Revised  FAR,  Pan  27,  Subpan  27.402(c)  clearly  directs  the  Government  to  consider  not  only 
shared  funding,  but  also  its  ultimate  requirements  before  determining  appropriate  rights  to  be 
acquired. 

We  believe  Subpan  27.404  should  contain  a  reference  back  to  27.402  to  assure  that  rights  issues 
will  be  properly  considered  where  mixed  funding  occurs,  and  that  GPR  will  be  stated  as  the  most 
stringent  Government  rights  possible  under  such  a  scenario.  Furthermore,  the  contractor  should 
always  be  allowed  to  claim  a  copyright  in  mixed-funding  situations. 

3.2J  Copyrights 

3.2J.1  Finding/Recommendation 

While  the  DFARS  copyright  license  includes  the  right  to  distribute  copies  to  the  public,  the  FAR 
does  not,  unless  what  is  known  as  the  Special  Works  clause  is  invoked  (Table  3-1). 

The  proposed  FAR,  Pan  27  revision  adopts  the  current  FAR  approach,  which  encourages 
commercialization.  The  final  Pan  27  must  retain  this  feamre. 

3.2J.2  Finding/Recommendation 

The  DFARS  and  FAR  automatically  allow  the  contractor  to  claim  a  copyright,  even  when  the 
Government  has  paid  for  development  (Table  3-1).  A  simple  discussion  of  why  copyrights  are 
important  at  all  is  lacking  in  the  DFARS. 

FAR  27.404(f)(l)(i)  is  somewhat  better  (but  not  by  much)  in  describing  how  the  contractor  is 
normally  granted  a  copyright  to  enhance  dissemination  of  information  produced  at  Government 
expense  (i.e.,  commercialize).  The  proposed  FAR,  Pan  27  revision  is  a  further  improvement,  but 
still  requires  enhancement  of  the  implementing  guidance.  The  current  NASA  FAR  supplement 
requires  proactive  Government  team  involvement  (including  patent  or  intellectual  property 
counsel)  in  determining  whether  a  contractor  has  specific  commercial  plans,  and  has  made  or  will 
make  a  significant  financial  contribution  to  the  development  or  maintenance  of  the  software.  The 
proposed  FAR,  Part  27  should  incorporate  more  of  the  NASA  supplement  language.  For  now, 
the  copyright  issue  is  most  readily  solved  by  not  invoking  today’s  Special  Works  clause  when 
the  contractor  demonstrates  a  commitment  to  commercialization.  This  will,  at  least,  give  the 
contractor  full  commercial  rights. 

3.2J.3  Finding/Recommendation 

If  a  contractor  cannot  claim  a  copyright  when  creating  a  derivative  work,  a  certain  degree  of 
incentive  is  necessarily  lost  because  of  the  unrealized  potential  for  commercialization. 

Alternate  incentives  must  be  used  to  offset  any  negative  derivative  work  copyright  issues.  Award 
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fees  could  be  used  to  partially  offset  potential  losses. 

3.2J.4  Finding/Recommendation 

Insufficient  attention  has  been  given  to  the  impact  of  copyrights  on  reuse  strategies.  The  issues 
we  have  identified  regarding  the  copyrighting  of  derivative  works  are  not  dispelled  by  the 
proposed  revision  in  FAR,  Subpart  27.404-5  and  its  associated  clause. 

Future  work  in  the  copyright  arena  must  begin  with  an  analysis  of  the  SEI  findings  on  copyrights. 
We  are  convinced  that  a  process  can  be  developed  to  satisfactorily  resolve  the  copyright  issue 
for  both  Government  and  commercial  software  reuse.  The  issue  of  patents  also  requires  further 
exploration. 

3.23.5  Finding/Recommendation 

The  FAR  approach,  which  is  more  favorable  to  industry  regarding  commercial  exclusivity  has 
been  adopted  in  the  proposed  FAR,  Part  27  revision.  However,  copyrights,  like  unlimited  rights 
and  GPR,  do  allow  full  disclosure  for  Government  purposes.  Therefore,  the  contractor’s 
incentive  to  partially  fund  creation  of  reusable  software,  or  to  put  its  best  talent  on  totally 
jovemment-funded  software  projects  remains  inhibited,  since  the  current  structure  doesn’t  enable 
the  contractor  to  benefit  from  Government-sponsored  reuse  of  its  products. 

Consequently,  a  policy  change  which  would  prevent  Government  disclosure  for  a  stated  period 
should  be  considered. 

3.2.4  Education/Training 

3.2.4.1  Finding/Recommendation 

We  believe  much  of  the  tension  between  industry  and  Government,  and  resulting  industry 
apprehension  is  created  by  a  lack  of  understanding  of  software  and  its  issues  by  federal 
acquisition  personnel.  This  is  compounded  by  inadequate  guidance  (DFARS)  to  help  accomplish 
effective  and  reasonable  software  acquisition  practices.  There  is  an  apparent  lack  of  a  concerted 
effort  to  provide  the  acquisition  work  force  with  new  guidance  to  improve  their  understanding 
of  software  acquisition. 

A  handbook  is  necessary  to  provide  acquisition  personnel  with  a  road  map  to  the  development 
of  effective  reuse  strategies.  It  should  be  written  for  the  experienced  acquisition  professional, 
not  as  a  tutorial  for  the  beginner. 

3.2.4.2  Finding/Recommendation 

Reuse  planning  in  today’s  environment  is  characterized  by  fragmented  efforts,  with  no  centi^ 
guidance  to  properly  focus  acquisition  personnel. 

We  believe  acquisition  planning  documents  (such  as  service  regulations  for  acquisition  strategy 
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meetings  and  DoD-STD-2167A)  should  require  assessment  of  existing  software  reuse  potential. 
3.2.4.3  Finding/Recommendation 

Software  is  not  delivered  to  the  "Government",  but  rather  to  a  particular  agency  or  office.  In 
most  cases,  other  agencies  are  totally  unaware  of  its  existence,  much  less  of  its  potential  utility 
to  their  problem/mission. 

An  agency  (or  set  of  agencies  -  by  service  or  command,  for  example)  that  acts  as  a  center  for 
receipt  of  software  separate  from  the  mission  organization  could  be  established  to  act  as  reuse 
advocates  in  the  procurement  process. 

3.2,5  Incentives 

3.2.5. 1  Finding/Recommendation 

Industry  is  reluctant  to  invest  in  new  technology  for  software  because  of  the  sweeping  rights 
demanded  by  the  Government,  and  concerns  regarding  loss  of  proprietary  information.  Much  of 
this  reluctance  arises  from  the  perception  that  the  DoD  will  always  try  to  insist  on  unlimited 
rights,  whether  it  needs  them  or  is  even  entitled  to  them. 

The  proposed  FAR  revision  must  include  clear  policy  statements  concerning  the  Government’s 
position  on  software  and  copyrights.  Our  recommendation  is  that  the  Government’s  stated 
preference  not  extend  beyond  Government  Purpose  Rights. 

3.2J.2  Finding/Recommendation 

The  mechanics  to  provide  royalty  payments  for  software  reuse  are  workable.  The  motivation  of 
both  parties  may  be  lacking,  however,  because  of  the  administrative  burden  and  lag  time  in 
payback. 

Royalties  are  an  avenue  not  yet  thoroughly  examined  and  exploited  in  reuse  strategy.  They  are 
successful  in  the  commercial  world,  though,  in  the  form  of  licenses  for  products.  More  guidance 
is  required  for  effective  royalty  use.  The  organization  recommended  in  3.2.4.3  above  could 
accept  these  administrative  tasks.  The  proposed  handbook  (3.2.4)  could  also  address  this  issue. 

3.2J.3  Finding/Recommendation 

Award  fees  are  being  used  today  to  promote  and  reward  reuse.  They  are  easily  structured  and 
create  very  little  administrative  burden  for  the  Government  and  industry. 

In  today’s  environment,  it  may  be  wise  to  consider  a  class  deviation  to  FAR  15.903(d),  allowing 
higher  award  fees  for  contracts  promoting  development  of  reusable  software  assets,  or  requiring 
that  software  assets  be  reused.  Since  FAR  15.903(d)  is  derived  from  statute,  revisions  to  the 
applicable  public  laws  may  also  be  required. 
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3.2J.4  Finding/Recommendation 

Our  understanding  and  interpreurion  of  FAR,  Part  48,  Value  Engineering  (VE)  is  that  it  can  be 
an  effective  vehicle  for  promoting  development/modification  of  reusable  software.  It  appears  to 
be  a  perfect  potential  vehicle  for  motivating  reuse  through  funding  support  and  incentive  rewards. 
Even  if  the  Government  retained  software  rights,  the  contractor  could  earn  incentives  which, 
incidentally,  would  not  be  subject  to  the  fee  limitations  in  FAR  15.903(d). 

A  test  program  should  be  selected  to  institute  a  software  reuse  VE  program. 

3.2S.S  Finding/Recommendation 

There  are  more  motivators  than  immediate  financial  rewards  to  incentivize  industry.  The 
Malcolm  Baldrige  Award  for  Quality  is  an  excellent  example. 

The  DoD  could  sponsor  a  similar  award  for  software  product  reuse,  using  the  Defense  Advanced 
Research  Projects  Agency  (DARPA)  as  the  selection  organization,  assisted  perhaps  by  industry, 
the  services  and  the  SEI.  Carried  further,  some  type  of  credit  could  be  conferred  on  the  award 
recipient  and  other  finalists  (to  a  lesser  degree)  in  DoD  competitions  (via  source  selection),  award 
fee  deliberations  and  profit  negotiations  using  weighted  guidelines. 

3.2.6  Liabilities 

3.2.6. 1  Finding/Recommendation 

People  within  and  outside  Government  immediately  raise  the  liability  specter  whci.  software  reuse 
is  discussed. 

We  do  not  believe  that  the  Government  should  attempt  to  offer  liability  protection  when  making 
software  assets  available  for  reuse.  It  is  not  a  practical  alternative,  and  would  require  a 
prohibitively  expensive  testing  and  administrative  organization.  The  Government  should  provide 
as  complete  a  description  as  possible  for  the  software.  The  contractor  will  then  have  sufficient 
information  available  to  make  an  intelligent  technical  and  business  decision  regarding  its  ability 
to  reuse  the  product  and  confidence  in  its  quality. 

3.2.7  Reuse  Strategies 

3.2.7.1  Finding/Recommendation 

There  are  no  overwhelming  impediments  in  the  current  DFARS/FAR  preventing  successful  reuse. 
However,  there  is  a  lack  of  adequate  guidance  and  training. 

The  proposed  handbook  (3.2.4)  should  incorporate  case  studies  on  successful  reuse  programs, 
as  well  as  guidance  (such  as  decision  trees)  in  creating  and  implementing  reuse  strategies. 
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3.2.7.2  Finding/Recommendation 

We  would  caution  against  mandating  reuse  unless  comprehensive  architecture  analysis  and  cost 
estimates  have  been  performed,  and  all  alternative  acquisition  strategies  have  been  examined  (for 
both  unlimited  and  restricted  rights  software). 

There  is  no  existing  formal  guidance  on  considerations  to  be  evaluated  in  assessing  reuse  viability 
in  a  program.  The  proposed  handbook  (3.2. 4>  and  current  acquisition  planning  documents 
should  be  revised  to  include  this  guidance. 

3.2.7.3  Finding/Recommendation 

A  company  will  embrace  reuse  when  it  believes  it  can  improve  its  volume  and  market  share 
positions. 

The  DoD  can  foster  that  concept  by  zealously  assuring  that  maximum  software  and  data  rights 
as  well  as  copyrights  pass  to  the  contractor.  This  would  motivate  the  contractor  to  pursue  reuse 
with  its  best  resources,  because  if  it  is  successful,  there  exists  the  potential  for  more  DoD  and 
commercial  business.  A  simple  DoD  policy  statement  could  effect  this  change  without  requiring 
alteration  of  the  current  DFARS. 

3.2.7.4  Finding/Recommendation 

The  current  DFARS  Interim  Rule  on  Recovery  of  Nonrecurring  Costs  on  Commercial  Sales 
(DFARS  52.235-7002)  has  negative  incentive  implications  for  software  reuse.  Industry  currently 
perceives  that  the  clause  creates  an  unfavorable  environment  for  commercialization.  This,  in  turn, 
impacts  the  creauon  of  reusable  software  if  the  contractor  believes  there  is  no  financial  incentive 
available. 

DFARS  52.235-7002  should  be  rescinded  or  a  cap  established  to  limit  the  Govemment’s  potential 
recovery,  and  the  regulation  should  clearly  state  that  the  Govemment’s  investment  base  is  limited 
to  contract  dollars. 

3.2.7.5  Finding/Reommendation 

The  current  DFARS/FAR  cenainly  do  .noi  prevent  reuse.  However,  they  do  impede  its  practice 
because  of  the  psychological  business  barriers  bel:e''ed  to  exist. 

Perhaps  it  is  time  to  reexamine  the  intent  of  the  Competition  in  Contracting  Act  regarding  the 
basis  for  other  than  full  and  open  competition.  The  purpose  would  be  to  assess  whether  changes 
are  needed  in  the  Act  to  facilitate  reuse,  and  whether  current  policy  interpretations  are 
unnecessarily  restrictive. 

3. 2.7.6  Finding/Recommendation 

Our  examination  of  the  current  strategies,  the  DFARS  and  FAR,  and  research  on  available 
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techniques  has  convinced  us  that  the  focus  on  business  considerations  must  match  the  technology 
efforts  to  assure  that  reuse  becomes  a  viable,  accepted  technology. 

Much  of  the  business  considerations  focus  can  be  accomplished  through  new  products  for 
educating  and  training  Government  acquisition  personnel  in  effective  reuse  strategies.  Persons 
in  all  disciplines  must  eventually  be  educated,  but  initial  efforts  must  be  targeted  toward  those 
persons  in  a  position  to  effect  the  greatest  change,  namely  program  managers,  contracting 
officers,  logisticians  and  legal  personnel. 
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4.  BUDGET/HNANCE  ENVIRONMENT 

4.1  The  Current  Budget/Finance  Environment  and  Proposed  Changes 

4.1.1  Introduction 

We  have  used  the  Air  Force  170  series  of  regulations  for  our  analysis  of  potential  impediments 
to  reuse  in  the  budget  and  finance  procedures.  We  were  at  least  partially  influenced  by  the 
currency  (15  October  1990)  and  comprehensiveness  of  AF  Regulation  (AFR)  172-1,  USAF 
Budget  Policies  and  Procedures.  It  represents  an  outstanding  compendium  of  the  intricacies  of 
budget  and  finance  issues.  Other  principal  reference  sources  were  AFR  177-16  (30  November 
1988),  Administrative  Control  of  Appropriations  and  the  AF  primer  on  the  Biennial  Planning, 
Programming,  and  Budgeting  System  (BPPBS,  January  1989)  issued  by  the  Directorate  of 
Program  and  Evaluation,  Deputy  Chief  of  Staff/Programs  and  Resources,  Department  of  the  Air 
Force.  The  bibliography  of  this  repon  identifies  the  remaining  documents  that  we  examined. 

Our  analysis  again  focuses  on  the  subject  of  software  reuse  and  actual  or  perceived  impediments 
to  its  implementation  and  proliferation.  The  background  information  in  section  3  of  this  report 
remains  applicable. 


4.1.2  The  Current  Budget/Finance  Environment 

Similar  to  our  description  in  the  FAR/DFARS  environment  section  (3.1.2),  software  is  not 
treated  separately  in  the  budget  regulations.  As  an  example,  AFR  172-1  addresses  software  as 
a  subset  (often  no  more  than  parenthetical)  of  the  hardware  application  discussion.  A  specific 
instance  is  the  treatment  of  general  purpose  (Information  Processing  Equipment  (IPE))  versus 
embedded  (integral  component  of  a  weapon  system)  computers.  IPE  software  (Vol.  I,  paragraph 
4-b,  4-f  of  AFR  172-1)  is  discussed  in  the  context  of  its  related  hardware,  and  is  funded  for 
purchase  through  the  Operation  and  Maintenance  (O&M)  account.  Software  for  embedded 
systems  is  discussed  in  paragraph  4-9.a.  This  paragraph  essentially  states  that  all  software 
developed  and/or  commercial  software  initially  integrated  (up  to  the  point  where  an  operational 
configuration  has  been  tested,  evaluated,  and  accepted  or  qualified)  will  be  acquired  with 
Research,  Development,  Test  and  Evaluation  (RDT&E)  funding.  In  all  this  discussion,  it’s  not 
clear  in  which  category  reuse  funding  would  fall.  If  one  were  modifying  existing  software  in  the 
Research  and  Development  (R&D)  phase  of  a  particular  weapon  system  with  embedded 
computers,  we  would  expect  RDT&E  funds  to  be  used.  However,  it  is  unclear  what  type  of  funds 
would  be  used  to  suppon  the  generic  modification  of  existing  software  to  be  used  across  new 
systems.  Perhaps  this  example  would  fall  under  fhroduct  Improvement  in  Vol.  I,  paragraph  8-3 
or  under  paragraph  4-9. e  for  embedded  systems,  both  providing  the  possibility  of  using  multiple 
funding  types  to  potentially  support  reuse.  Program  managers  do  not  have  the  necessary  budget 
guidance  to  clearly  depict  how  software  reusability  (outside  the  normal  development  process) 
should  be  properly  funded,  and  funding  guidelines  are  inadequate  to  address  these  needs. 
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4.1J  Impact  of  Reuse  in  a  Declining  Defense  Budget 

There  is  a  real  danger  that  investment  in  reuse  will  be  viewed  as  unaffordable  in  today’s 
declining  Defense  budget.  In  a  speech  to  the  TRI-Ada  ’90  Conference,  LtG  James  S.  Cassity, 
Jr.  stated  mat  the  DoD  budget  will  have  decreased  25%  in  real  dollars  over  the  period  from  1985 
to  1995.  He  went  on  to  cite  that  software  development  consumes  10%  of  today’s  total  Defense 
budget,  with  80%  of  those  dollars  expended  for  software  maintenance  and  upgrade.  There  are 
a  number  of  points  to  be  gleaned  from  the  General’s  remarks,  not  one  of  which  maintains  that 
reuse  is  not  an  affordable  initiative.  On  the  contrary,  reuse  has  the  potential  to  soften  the  impact 
of  a  declining  budget  by  reducing  new  software  development  costs,  using  proven  software  with 
the  effect  of  reducing  maintenance  costs,  and  providing  software  and  software  products  which 
make  upgrades  more  affordable. 

4.1.4  Advocacy 

Notwithstanding  the  positive  potential  impact  of  reuse  on  the  budget,  it  will  be  very  difficult  in 
today’s  environment  of  strict  budgeting  constraints  to  promote  any  reuse  strategy  which  requires 
an  unanticipated  investment.  Program  managers  have  to  believe  that  it’s  worth  their  while  to 
invest  today’s  dollars  for  tomorrow’s  payoff,  or  that  there  will  be  support  for  such  an  investment 
even  when  the  program  may  not  have  sufficient  initial  funding  to  implement  a  reuse  strategy. 
This  can  be  fostered,  in  pan,  by  formally  establishing  reuse  advocacy  in  the  Office  of  the 
Secretary  of  Defense  (OSD)  and  the  services,  including  the  identification  of  senior  individuals 
to  sponsor  reuse.  We  are  not  recommending  the  establishment  of  a  new  reuse  advocate  position 
in  each  organization.  Rather,  we  recommend  that  an  appropriate  senior  official  in  each 
organization  who  is  already  responsible  for  software  be  given  the  charter  for  reuse  advocacy. 
This  individual  should  be  in  a  position  in  which  his/her  office  would  normally  be  involved  (or 
could  easily  become  involved)  in  requirements  validation,  program  direction  documentation, 
budgeting  formulation  cycles,  and  acquisition  strategy  planning  and  execution.  These  interfaces 
are  necessary  to  assure  that  reuse  is  properly  considered  in  the  requirements  definition,  funding 
and  program  execution  processes.  OSD  and  the  services  currently  are  structured  to  easily 
accommodate  this  recommendation. 

The  advocacy  position  is  important  because  reuse  is  not  widely  understood  or  practiced  today. 
While  reuse  technology  is  proven,  it  is  continually  evolving.  Therefore,  senior  management 
influence  and  oversight  are  required  to  ensure  effective  implementation  and  institutionalization. 
Over  time,  we  would  expect  formal  advocacy  to  become  unnecessary,  since  reuse  would 
continually  demonstrate  its  effectiveness. 

4.1.5  Investment  Requirements 

While  the  establishment  of  a  reuse  advocate  would  represent  a  positive  and  bold  initiative,  it’s 
not  sufficient  to  ensure  success.  Reuse  will  add  investment  dollars  to  some  programs  in  which 
software  is  being  developed,  modified  or  improved  with  the  intent  of  future  reuse.  Where  will 
the  money  come  from?  Even  in  today’s  environment,  there  will  be  programs  which  can  afford 
the  investment  within  their  current  budget  profiles.  However,  most  others  can  not  support  such 
an  investment.  Therefore,  we  recommend  that  DARPA  and  the  services  sponsor  initiatives  to 
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create  reuse  technology  budgets  under  Program  Elements  (PE).  The  PEs  would  address  the 
development  of  reuse  technology,  the  funding  for  new  programs  which  would  benefit  from  reuse 
but  do  not  have  sufficient  resources  to  implement  the  strategy,  and  dollars  to  modify/improve 
existing  software  products  to  make  them  reusable.  We  are  not  so  naive  as  to  expect  that  this  will 
be  easy  to  accomplish  or  that,  even  if  success  were  demonstrated,  it  would  have  more  than  a 
modest  budget  initially.  We  are  confident,  however,  that  it  would  prove  its  worth  and  eventually 
be  soundly  supported  in  the  years  to  come. 

The  PE  could  even  be  established  as  a  management  fund  (see  APR  172-1,  Vol  I,  Chapter  11). 
Under  this  type  of  fund,  there  is  an  opponunity  for  reimbursement  of  investment  dollars  to  the 
PE  if  development,  production  or  maintenance  costs  are  reduced.  Depending  on  when  (and  if) 
the  reimbursement  occurs,  these  dollars  might  be  available  to  help  other  programs.  The 
management  fund  concept  would  reinforce  the  notion  of  "investment  now  means  payback/savings 
later",  and  perhaps  make  reuse  a  more  inviting  concept  to  pursue. 

4.1.6  Program  Executive  Officer  (PEO) 

We  also  recommend  that  each  service  provide  financial  resources  and  a  charter  (Program 
Management  Directive  (PMD)  language)  to  support  reuse,  and  that  each  PEO  provide  the 
management  advocacy  so  necessary  to  successful  reuse.  Given  the  PEO’s  broad  acquisition 
charter  across  a  common  family  of  programs,  there  is  significant  opportunity  to  provide  reuse 
investment  resources  in  one  PEO  program  with  the  potential  of  benefrtting  many  other  programs 
or  program  components  under  the  PEO’s  management  Some  PEOs  may  view  this  as  an 
intrusion  into  their  management  authority  and  prerogative;  however,  we  contend  that  it  is 
necessary  even  if  viewed  in  this  context.  The  greater  DoD  mission  and  its  budget  constraints 
demand  that  we  aggressively  seek  opportunities. 

4.1.7  Funding  Types  and  Use 

There  are  three  types  of  funds  typically  used  for  software,  which  could  also  fund  reuse  efforts: 
Research,  Development,  Test  and  Evaluation;  Production;  and  Operation  and  Maintenance.  Each 
has  a  different  life  cycle,  starting  in  the  year  the  funds  are  appropriated  by  Congress:  2  years  for 
RDT&E;  3  years  for  Production  and  1  year  for  O&M.  These  funds  must  be  obligated  (placed 
on  contract)  within  the  stated  periods.  The  funds  remain  available  for  two  years  following  the 
conclusion  of  these  periods  for  payments,  after  which  they  lapse  into  what  is  known  as  a  merged 
or  M  account. 
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Reuse  can  be  introduced  at  any  time  in  an  acquisition  life  cycle.  The  following  diagram  shows 
what  type  of  funds  would  be  used  for  particular  acquisition  phases  where  software  reuse  might 
be  employed.  Typically,  the  same  type  and  year  of  funds  required  for  the  basic  effon  would  be 
expected  to  fund  reuse.  For  example,  a  reuse  product  improvement  identified  against  an  FY91 
requirement  would  use  that  year’s  funds. 


Acquisition 

Period 

Funding  Type 

RDT&E 

Production 

O&M 

Research  &  Development 

• 

Production 

• 

• 

Engineering  Change 

• 

• 

• 

Product  Improvement 

• 

• 

• 

Aircraft  Modifications 

• 

• 

• 

Funding  for  Software  Acquisitions 

Some  production  portions  of  contracts  (product  improvements  and  aircraft  modifications)  might 
require  different  fiinding  types  dependent  upon  the  nature  and  timing  of  the  change.  This  is  not 
a  significant  issue  unless  identified  outside  the  budget  cycle  (discussed  later). 

There  are  two  potential  impediments  to  reuse  in  the  area  of  funding  types  and  uses.  Both  are 
more  perceived  than  real.  The  first  concerns  the  manner  in  which  software  is  treated  in  the 
regulations;  the  second  issue  deals  with  annual  appropriations  language.  We  would  favor  a 
sinople  matrix  which  shows  that  reuse  investment  can  be  made  from  essentially  any  of  the  three 
funds  identified,  appropriate  to  the  specific  phase  of  a  particular  program’s  acquisition  life  cycle. 
While  some  will  argue  that  today’s  guidance  is  adequate,  we  cannot  agree  (see  paragraph  4.1.2 
for  a  more  detailed  discussion).  Handbook  material  should  be  developed  to  interpret  current 
regulations  and  provide  specific  guidance. 

We  have  heard  arguments  stating  that  funds  earmarked  for  a  specific  program  (in  a  PE)  cannot 
be  expended  on  reuse.  Essentially,  some  are  arguing  that  program-  specific  dollars  cannot  be 
spent  for  software  development  to  make  it  reusable  across  other  programs.  This,  it  is  argued, 
would  be  expenditure  of  the  funds  for  a  purpose  not  originally  intended.  We  do  not  agree,  but 
we  were  puzzled  about  the  origination  of  this  perception.  Our  research  suggests  that  it  traces 
back  to  the  now  annual  language  cited  in  31  USC  1301(a)  (see  AFR  177-16,  para.  4.0)  which 
states,  "Appropriations  shall  be  applied  only  to  the  objects  for  which  the  appropriations  were 
made  except  as  otherwise  provided  by  law”.  We  understand  that  the  language  would  prohibit, 
for  example,  the  use  of  funds  under  the  B-2  PE  to  support  development  of  a  new  targeting 
satellite.  It  stretches  interpretation  beyond  credibility,  though,  to  say  that  B-2  funds  could  not 
be  used  in  developing  its  avionics  software  in  a  manner  that  would  also  make  it  reusable  across 
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other  airborne  platforms.  The  Congressional  intent  was  to  prohibit  the  undermining  of  specific 
legislative  authorizations  regarding  program  starts,  modifications  and  continuance.  We  are 
convinced  that  no  legislator  would  argue  or  interpret  this  statutory  language  so  narrowly  as  to 
act  against  a  technology  concept  which  not  only  makes  software  more  affordable  across 
programs,  but  also  makes  software  more  structured  and  maintainable  within  programs. 
Nonetheless,  we  recommend  provision  of  handbook  guidance  on  how  to  implement  reuse  funding 
and  budgeting,  in  addition  to  specific  legislative  language  endorsing  use  of  program  funds  to 
foster  reuse. 

4.1.8  The  Budget  Process  Impact  on  Reuse 

We  are  currently  in  fiscal  year  1991  (FY91).  Near-tenn  specific  funding  for  reuse  is  difficult 
unless:  (1)  a  funded  program  can  support  it;  (2)  a  general  fund  for  software  (such  as  STARS) 
exists  to  fund  reuse  strategies;  or  (3)  formal  reprogramming  (moving  funds  from  one  PE  to 
another)  is  accomplished.  FY92  prospects  are  no  better.  The  budget  cycle  initiates 
approximately  18  months  prior  to  the  fiscal  year.  The  FY92  budget  cycle  started  its  formal 
process  in  April,  1990,  and  is  now  being  finalized  as  the  President’s  budget  is  to  be  submitted 
to  Congress  during  February,  1991.  Unless  already  identified  in  the  FY92  budget  (in  a  manner 
as  described  above),  there  is  scant  opportunity  to  provide  additional  support  for  reuse  and 
effective  reuse  strategies  during  that  fiscal  year.  The  management  fund  concept  we  identified 
may  not  be  possible  until  FY94,  because  the  FY92  budget  also  introduced  the  biennial  DoD 
budget,  and  FY93  is  essentially  fixed  now  except  for  an  execution  review  which  will  occur 
during  the  spring  of  1991.  However,  we  strongly  recommend  that  DARPA  and  the  services 
suppon  a  spring  1991  initiative  in  the  execution  review  of  the  FY93  budget  which  would 
introduce  reuse  funding  and  adopt  the  management  fund  concept.  Similarly,  the  FY94  budget 
can  now  be  planned.  We  would  also  encourage  FY92  reprogramming  of  funds  to  programs  with 
near-term,  measurable  benefits  to  be  realized  through  reuse. 

4.1.9  Conclusion 

The  budget  process  creates  impediments  to  reuse  due  to  its  lengthy  and  increasingly  intractable 
process.  Until  reuse  is  recognized  as  an  essential  acquisition  strategy  element  and  integrated  into 
the  program  budget  process,  we  will  play  a  game  of  catch  up,  which  has  already  begun.  It  is 
critical  to  maintain  the  momentum,  point  to  successes  and  achieve  the  recommendations  outlined 
here. 

4.2  Finding/Recommendation 

The  following  findings  and  recommendations  are  based  on  the  concepts  and  ideas  expressed 
within  section  4.1.  We  have  also  drawn  on  our  extensive  review  of  supporting  documentation 
(Appendix  C).  Our  attendance  at  Government  and  industry  briefings,  conferences  and  workshops, 
coupled  with  numerous  interviews  has  provided  us  with  an  invaluable  source  of  information  and 
innovative  ideas  (Appendix  B). 
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4.2.1  Ease  of  Use 

4.2.1.1  Finding/Recommendation 

Comparable  to  what  we  described  in  the  FAR/DFARS  environment,  software  is  not  treated  as 
a  separate  entity  in  the  budget  regulations.  Today’s  program  managers  do  not  have  the  necessary 
policy  and  budget  guidance  to  clearly  specify  how  software  and  software  reusability  should  be 
funded. 

Regulations  addressing  Budget  Policies  and  Procedures  should  be  revised  to  treat  software 
(including  software  reuse)  separately  from  hardware.  Handbook  material  should  be  developed 
to  interpret  current  regulations  and  provide  specific  guidance. 

4.2.2  Reuse  Investment 

4.2.2.1  Finding/Recommendation 

There  is  a  real  danger  that  investment  in  reuse  will  be  viewed  as  unaffordable  in  today’s 
declining  Defense  budget.  However,  reuse  has  the  potential  to  soften  the  impact  of  a  declining 
budget  by  reducing  new  software  development  costs,  using  proven  software  with  the  effect  of 
reducing  maintenance  costs,  and  providing  software  and  software  products  which  make  upgrades 
more  affordable. 

We  recommend  that  each  service  provide  financial  resources  and  a  charter  (PMD)  to  support 
reuse.  PEOs  must  also  provide  the  management  advocacy  so  necessary  for  successful  reuse. 

4.2.2.2  Finding/Recommendation 

It  costs  money  to  make  software  reusable.  Reuse  will  add  investment  dollars  to  programs  in 
which  software  is  being  developed,  modified  or  improved  for  reuse  purposes. 

We  recommend  that  DARPA  and  the  services  sponsor  initiatives  to  create  reuse  technology 
budgets  under  Program  Elements. 

4.2J2.3  Finding/Recommendation 

We  are  currently  in  fiscal  year  1991  (FY91).  Near-term  specific  funding  for  reuse  is  difficult 
unless:  (1)  a  funded  program  can  suppon  it;  (2)  a  general  fund  for  software  (such  as  STARS) 
exists  to  fund  reuse  strategies;  or  (3)  formal  reprogramming  (moving  funds  from  one  PE  to 
another)  is  accomplished. 

We  strongly  recommend  that  DARPA  and  the  services  support  a  spring  1991  initiative  in  the 
execution  review  of  the  FY93  budget,  which  would  introduce  reuse  funding  and  adopt  the 
management  fund  concept.  We  would  also  encourage  FY92  reprogramming  of  funds  to  programs 
with  near-term,  measurable  benefits  to  be  realized  through  reuse. 
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4.2 J  Education  and  Training 

4.23.1  Finding/Recommendation 

We  have  heard  arguments  stating  that  funds  earmarked  for  a  specific  program  (in  a  PE)  cannot 
be  expended  on  reuse.  Our  research  suggests  that  it  traces  back  to  the  now  annual  language  cited 
in  31  use  1301(a)  (see  APR  177-16,  para.  4.0)  which  states,  "Appropriations  shall  be  applied 
only  to  the  objects  for  which  the  appropriations  were  made  except  as  otherwise  provided  by  law '. 

The  Congressional  intent  was  to  prohibit  the  undermining  of  specific  legislative  authorizations 
regarding  program  starts,  modifications  and  continuance.  However,  the  legislative  language  does 
not  prohibit  allocation  of  specific  program  funds  for  reuse.  Therefore,  handbook  guidance  on 
how  to  implement  reuse  funding  and  budgeting  is  required.  We  also  recommend  that  the 
legislature  provide  specific  language  endorsing  use  of  program  funds  to  foster  reuse. 

4.2.4  Advocacy 

4.2.4.1  Finding/Recommendation 

Notwithstanding  the  positive  potential  impact  of  reuse  on  the  budget,  it  will  be  very  difficult  in 
today’s  environment  of  strict  budgetary  constraints  to  promote  any  reuse  strategy  which  requires 
an  unanticipated  investment. 

A  reuse  advocate  should  be  designated  in  the  Office  of  the  Secretary  of  Defense  (OSD)  and  the 
services,  in  addition  to  the  identification  of  senior  individuals  to  sponsor  reuse.  We  do  not 
recommend  establishing  a  new  reuse  advocate  position  in  each  organization.  Rather,  we 
recommend  that  an  appropriate  senior  official  in  each  organization  who  is  already  responsible  for 
software  be  given  the  charter  for  reuse  advocacy. 
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Table  3-2  Software  Acquisition  Scenarios 
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AFATDS 

ATCCS 

ATF 

AWDS 

BPPBS 

C'l 

CCPDSR 

CMU 

DARPA 

DFARS 

DoD 

DoD-STD-2167A 

FAR 

FY 

GPLR 

GPR 

IPE 

JIAWG 
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APPENDIX  A 

ACRONYMS 

Advanced  Field  Anillery  Tactical  Data  System 

Army  Tactical  Command  and  Control  System 

Advanced  Tactical  Fighter 

Automated  Weather  Distribution  System 

Biennial  Planning,  Programming,  and  Budgeting  System 

Command,  Control,  Communications  and  Intelligence 

Command  Center  Processing  and  Display  System  Replacement 

Carnegie  Mellon  University 

Defense  Advanced  Research  Projects  Agency 

DoD  Federal  Acquisition  Regulation  Supplement 

Department  of  Defense 

Defense  System  Software  Development  Standard 
Federal  Acquisition  Regulation 
Fiscal  Year 

Government  Purpose  License  Rights 
Government  Puipose  Rights 
Information  Processing  Equipment 
Joint  Integrated  Avionics  Working  Group 
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NASA 

NRL 

O&M 

OSD 

PE 

PEO 

PMD 

R&D 

RDT&E 

RFP 

SDIO/NTBJPO 

SEI 

STARS 

TR 

UNAS 

use 


APPENDIX  A  (con’t) 

National  Aeronautics  and  Space  Administration 

Naval  Research  Laboratories 

Operation  and  Maintenance 

Office  of  the  Secretary  of  Defense 

Program  Element 

Program  Executive  Officer 

Program  Management  Directive 

Research  and  Development 

Research,  Development,  Test  and  Evaluation 

Request  for  Proposal 

Strategic  Defense  Initiative  Organization/National  Test  Bed  Joint 

Program  Office 

Software  Engineering  Institute 

Software  Technology  for  Adaptable,  Reliable  Systems 

Technical  Repon 

Universal  Network  Architecture  Services 
United  States  Code 
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Personnel  Interviewed  /  Contacted 


Individual 

Organization 

Date  (90) 

Robert  Kent 

Jim  Henslee 

ESD/AVS 

13  July 

Capi.  Rothrock 

Joanne  Piper 

RAPID 

2  August 

Bob  DiBona 

SofTech 

Bob  Roe 

George  Hadley 

Boeing 

14  August 

Robert  Kent 

ESD/AVS 

16  August 

Dennis  Turner 

CECOM 

27  August 

Ed  Gallagher 

Jerry  Brown 

Dr.  Marty  Wolfe 

Mike  Zelinki 

28  August 

Dr.  Mary  Shaw 

SEI 

11  September 

John  Foreman 

1''  September 

Bob  Halibaugh 

Rick  DTppolito 

Jeff  Stewart 

Ken  Lee 

Charles  Plinta 

September 

Pam  Samuelson 

Univ  of  Pitt 

13  September 

Sholom  Cohen 

SEI 

14  September 

Major  Mather 

SAF/AOC 

18  September 

Dr.  Tom  Frazier 

19  September 

Dr.  Betsy  Baily 

Bruce  Angier 

IDA 

LtC.  Gross 

Office  Asst  Secv  for 
Comm/Como/Loe-AF 

19  September 

LtC.  Adams 

Major  Nelson 

USAF/LE 

Jim  Hess 

Office  Asst  Secv  of 
Armv  for  RDA 

20  September 

Linda  Nielson 

DAR  Council 

20  September 

Bruce  Gray 

Stan  Levine 

CECOM 

2  October 

B-l 
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Personnel  Interviewed  /  Contacted 


Individual 

Organization 

Date  (91) 

Hans  Polzer 

Unisvs 

11  October 

Major  Baxter 

Office  of  the 

15  October 

Tony  Lane 

Judge  Advocate 

Earl  Reichan 

General  -  Armv 

Robert  Kempf 

NASA 

15  October 

Bonnie  Dancy 

EVB 

16  October 

Dave  Ceely 

IBM 

16  October 

Jack  Cooper 

Anchor  Software 
Management 

17  October 

Steve  Grimaldi 

ARINC 

17  October 

John  Gaffney 

Robert  Cruickshank 

SPC 

18  October 

Alec  Grindlay 

Dr.  Raghu  Singh 

SPAWARS 

18  October 

LtC.  Boyle 

Dent  of  the  Armv 
(STARS) 

19  October 

LtC.  Morrison 

SDIO  /  NTBJPO 

25  October 

Boyd  Clark 

Jim  Frahn 

Barry  Lauritzen 

Marty  Wyatt 

Loral 

25  October 

Dr.  Ron  Green 

USA  SDS 

31  October 

Jay  Crawford 

Naw  (China  Lake) 
JIAWG 

9  November 

FAR  Council 

Public  Hearing  on 
Advanced  Notice  of 
Protx)sed  Change  to 

FAR  Part  27  and 

DFARS  227 

19  November 

Dr.  Jack  Kramer 

DARPA/STARS  PM 

20  November 

Walker  Royce 

TRW 

27  November 

Bob  Wasilausky 

NOSC  28  November 

Karen  Mackey 

ESL 

29  November 

Don  Reifer 

Reifer  Consultants 

5  December 

LtC.  Lyons 

WPAFB/ATF  (JIAWG) 

6  December 

Frank  Poslajko 

USA  SDS 

11  December 

Christopher  Stone 

Obiect  Management 

GrouD 
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Personnel  Interviewed  /  Contacted 


Individual 

Organization 

Date  (91) 

Harley  Ham 

Naval  Avionics  Center 

9  January 

Alan  Impicciche 

Bruce  Pulliam 

Ed  Gallagher 

CECOM 

11  January 

Walt  Truszkowski 

Goddard  Soace  Flisht 

14  January 

Elizabeth  Wald 

Center/NASA 

NRL 

15  January 

Joe  Fox 

Software  A  &  E 

15  January 

Whit  Ludington 

ARINC 

15  January 

Jim  Hess 

Office  Asst  Secv  of 

16  January 

Bonnie  Danner 

Armv  for  RDA 

TRW 

16  January 

LtC.  Gross 

Office  Asst  Secv  for 

17  January 

LtC.  Adams 

Comm/Comn/Loe-AF 

USAF/LE 

17  January 

Major  Nelson 

William  Carlson 

Intermetrics 

18  January 

Shirley  Pealc 

Fleet  Combat  Direction 

22  January 

Tom  Coneeney 

Dr.  Tom  Frazier 

Svstem  SuDDon  Activitv 
IDA 

24  January 

Bruce  Angier 

Kathy  Wilson 

Dr.  Dennis  Aheam 

Westinehouse  Electric 

25  January 

Chuck  McNally 

Dr.  Jack  Kramer 

DARPA/STARS  PM 

29  January 

B-3 


STARS-SC-03501A)01A)0 
STARS-SC-03504/(X) 1 AX) 


30  March  1991 


APPENDIX  C 

BIBLIOGRAPHY 

1)  Federal  Acquisition  Regulation  (FAR)  (1989) 

2)  Department  of  Defense  FAR  Supplement  (1988) 

3)  National  Aeronautics  &  Space  Administration  Far  Supplement  Directive  (NFSD)  89-0, 
Subpan  18-27.4,  30  Jun  89,  89-1,  Subpan  18-52.227-86,  30  Sep  89 

4)  Advanced  Notice  of  Proposed  Rulemaking  (FAR  Subpan  27;  DoD  FAR  Supplement  Interim  Rule 
Subpan  227),  Federal  Register,  Vol.  55,  No.  199,  15  Oct  90 

5)  Technical  Repon  CMU/SEI-86-TR-1,  "Toward  a  Reform  of  the  Defense  Department  Software 
Acquisition  Policy" 

6)  Technical  Repon  CMU/SEI-86-TR-2  ESD-TR-86-203,  "Proposal  for  a  New  "Rights  in  Software" 
Clause  for  Software  Acquisitions  by  the  Department  of  Defense" 

7)  Technical  Report  CMU/SEI-87-TR-4  ESD-TR-86-104,  "Software  and  System  Warranty  Issues 
and  Generic  Warranty  Clause" 

8)  Technical  Repon  CMU/SEI-87-TR-13  ESD-TR-87-114,  "Seeking  the  Balance  Between 
Government  and  Industry  Interests  in  Software  Acquisitions" 

9)  Technical  Report  CMU/SEI-87-TR-16  ESD-TR-87-1 17,  "Preliminary  Report  on  Conducting  SEI- 

Assisted  Assessiuenio  of  S  /.-iv^ar*  Ci»fibility" 

10)  Technical  Report  CMU/SEI-87-TR-23  ESD-TR-87-1 86,  "A  Method  for  Assessing  the  Software 
Engineering  Capability  of  Contractors" 

11)  Technical  Re^rt  CMU/SEI-87-TR-42  ESD-TR-87-205,  "Issues  in  Software:  A  Blue  Two  Visit 
Feasibility  Assessment" 

12)  Technical  Report  CMU/SEI-88-TR-1  ESD-TR-88-002,  "Summary  of  SEI  Technical  Operations: 
1987" 

13)  Technical  Report  CMU/SEI-88-TR-22  ESD-TR-88-023,  "Perspective  on  Software  Reuse" 

14)  Technical  Report  CMU/SEI-89-TR-6  ESD-89-TR-6,  "Proceedings  of  the  Workshop  on  Executive 
Software  Issues,  2-3  Aug  88  and  18  Nov  88" 


C-1 


30  March  1991 


STARS-SC-03501AX)1AX) 
STARS-SC-03504AX)  1/00 


APPENDIX  C  (con’t) 

15)  Technical  Report  CMU/SEI'89-TR-7  ESD-TR-89-07,  "Conducting  SEI- Assisted  Software  Process 
Assessments" 

16)  Technical  Memorandum  SEI-86-TM1,  "Adequate  Planning  for  Acquiring  Sufficient 
Documentation  about  and  Rights  in  Software  to  Permit  Organic  or  Competitive  Maintenance" 

17)  Technical  Memorandum  SEI-86-TM2,  "Comments  on  the  Proposed  Defense  and  Federal 
Acquisition  Regulations" 

18)  Technical  Memorandum  SEI-86-TM3,  "Understanding  the  Implications  of  Selling  Rights  in 
Software  to  the  Defense  Department;  A  Journey  Through  the  Regulatory  Maze" 

19)  Defense  Acquisition  Board  and  Science  and  Technology  Comminee  Software  Working  Group, 
Department  of  Defense  Software  Master  Plan  (preliminary  draft),  9  Feb  90 

20)  Air  Force  Software  Management  Group,  Air  Force  Software  Management  Plan,  20  Aug  90 

21)  Gross,  R,  Lt.Col.,  "Repon  of  the  DoD  Ad  Hoc  Software  Reuse  Strategy  Group  Meeting,  March 

29-30,  1989",  15  May  89 

22)  Joint  Integrated  Avionics  Working  Group  Software  Task  Group,  "JlAWG  Reusable  Software 
Program  Operational  Concept  Document  (draft)",  30  Sep  90 

23)  Joint  Integrated  Avionics  Working  Group  Software  Task  Group,  Reuse  Subcommittee, 
"Instructions  to  2167A  DI-MCCR-80030A  Software  Development  Plan  (draft)",  25  Jun  90 

24)  Bollinger,  T.  and  Barnes,  B.,  "Making  Software  Reuse  Cost  Effective",  Contel  Corporation,  14 
Jun  90 

25)  SDS  (Strategic  Defense  System)  Software  Reuse  Strategy  Document  (draft),  Nov  90 

26)  SDS  (Strategic  Defense  System)  Software  Reuse  Committee  Action  Plan  (draft), 

Nov  90 

27)  Advanced  Field  Artillery  Tactical  Data  System  (AFATDS)  Award  Fee  Determination  Plan, 
Revision  K,  30  Mar  90 

28)  Joint  Integrated  Avionics  Working  Group  Software  Task  Group,  "Contract  Elements  for  Software 
Reuse  (draft)",  13  Jun  90 

29)  Morrison,  J.S.,  Lt.Col.,  USAF,  "Planning  for  Software  Reuse  in  SDI",  National  Test  Bed  Joint 
Program  Office,  Falcon  AFB,  CO,  19-20  Jul  89 


C-2 


30  March  1991 


STARS-SC-03501AX)1/00 

STARS-SC-03504AX)1A)0 


APPENDIX  C  (con’t) 

30)  Cooper,  J.,  "Reusable  Software  Business  Issues"  Summary  Charts  from  NSIA,  Anchor  Software 
Management,  Ltd. 

31)  "The  Business  Issues  Associated  With  Software  Reuse",  National  Security  Industrial  Association, 
15  Dec  90 

32)  Comptroller  Activities,  Functions,  and  Responsibilities,  Feb  87,  AFR 170-6 

33)  Accounting  For  Obligations,  Aug  88,  AFR170-8 

34)  Definitions  of  Expense  and  Investment  Costs,  Nov  66,  AFR170-14 

35)  Avoiding  Violations  of  the  Anti-Deficiency  Act  (RS3679),  Aug  82,  AFP170-19 

36)  USAF  Budget  and  Procedures,  Dec  86,  AFR172-1,  Oct  90 

37)  The  Air  Force  Budget  Process,  Oct  87,  AFR172-4 

38)  Independent  Cost  Analysis  Program,  Oct  86,  AFR173-11 

39)  Administrative  Control  of  Appropriations,  Nov  88,  AFR  177- 16 


C-3 


30  March  1991 


STARS-SC-03501/001/00 

STARS-SC-03504A)01/CX) 


APPENDIX  D 


Comments  on  the  Advanced  Notice  of  Proposed  Rulemaking  for  the  Proposed  FAR,  Subpan  27.4 
-  Rights  in  Data  and  Copyrights 


This  Appendix  consists  of  the  following  Segments: 


Tasking  Synopsis  D-2 

General  Comments  D-3 

Specific  Comments  D-4-6 

Repon  Extractions  D-7-11 
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TASKING  SYNOPSIS 

Reusable  Software  Acquisition  Environment  (DSD  Laboratories) 

The  purpose  of  this  task  is  :  To  investigate  and  identify  current  business  impediments  to  the 
reuse  of  software;  and  to  enhance  software  reusability  through  the  establishment  of  a  framework 
for  industry  incentives  to  commercialize  reusable  software  packages.  Two  major  areas  have  been 
identified  for  study: 

Area  1:  Incentives  must  be  established  to  reward  contractors  who  engineer  reusability 
into  their  software  development  lifecycle.  This  will  require  the  identification  and 
modification  of  any  regulation,  policy  or  procedure  which  impedes  the  establishment  of 
such  incentives.  These  incentives  could  take  the  form  of  specific,  increased  funding  to 
contractors  incorporating  reusability  into  their  software  development  efforts. 

-  The  Federal  Acquisition  Regulation  (FAR)  and  the  DoD  FAR  Supplement  as 
well  as  service  supplements  will  be  examined  for  impediments  in  the  way  data 
rights  are  acquired  and  software  is  contracted. 

-  Budgeting  and  program  financing  regulations  and  policies  will  be  reviewed  to 
identify  unnecessary  restrictions  and/or  disincentives  to  providing  financial 
resources  for  engineering  software  reusability. 

-  Procedures  and  processes  for  providing  program  directions  and  acquisition 
strategy  guidance  will  be  examined  for  opportunities  to  emphasize  and 
institutionalize  the  concept  of  engineered  software  reusability.  Techniques  such 
as  license  rights  to  developing  contractors;  cataloging  of  software  products  across 
functional  lines  (by  industry  or  government);  and  other  business  incentives  and 
processes  to  stimulate  commercial  custodianship  and  marketing  of  reusable 
software  packages  will  be  identified,  critiqued,  legitimized  and  presented  in  the 
proper  regulatory  or  procedural  firamework  for  DoD  implementation.  Ease  of  use 
will  be  the  basis  for  any  methodology  developed. 

Area  2:  Examine  the  feasibility  and  utility  of  applying  the  techniques  listed  above  on  an 
"across  the  board"  versus  selective  basis.  Reusability  effectiveness  may,  for  instance,  be 
most  promising  across  a  given  functional  area  (e.g.  Command  and  Control),  but  only 
when  programs  exceed  thresholds  in  terms  of  program  value,  anticipated  length  of 
software  development  cycle  or  other  significant  parameters.  We  will  insure  that  our 
recommendations  are  based  on  assessments  from  all  functional  areas  within  the 
development,  acquisition  and  using  communities. 

After  an  initial  effectiveness  screening,  those  concepts  and  issues  meriting  further  study  will  be 
processed  within  the  firework  described  in  the  two  major  study  areas. 
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(1)  The  proposed  Subpart  27.4  continues  to  maintain  combined  coverage  for  both  technical 
data  and  software.  At  the  November  19,  1990  Public  Hearing  on  the  Advance  Notice, 
the  Council  stated  this  combined  coverage  was  retained  because  it  believed  there  were 
more  similarities  than  differences  between  Technical  Data  and  Software.  We  maintain 
the  existence  of  differences  is  precisely  why  the  topics  must  be  treated  separately. 
Software  deals  in  restricted,  not  limited  rights.  Software  copyright  issues,  especially  with 
regard  to  software  reuse,  are  conceptually  and  fundamentally  different  from  those  for 
Technical  Data.  Continuing  to  combine  the  topics  unnecessarily  complicates  and  confuses 
issues.  If  the  council  pubUcly  (Federal  Register)  expressed  its  intent  to  separate  the 
topics,  we  would  be  happy  to  participate  in  the  rewrite.  We  do  not  have  the  resources 
to  engage  in  this  substantial  effort  without  knowing  it  would  reach  fruition. 

(2)  Subpart  27.4  remains  poorly  organized  and  is  written  for  those  with  a  legal  background. 
The  basic  rights  in  data  clause  (notice  no  software  mentioned  in  the  title)  (52.227-14)  is 
a  classic  example.  It  rambles  for  pages,  loosing  the  reader  in  its  depth  and  breadth.  We 
recommend  the  council  follow  the  insurance  industry  which  was  forced  to  rewrite  its 
policies  so  a  layman  could  have  more  potential  for  understanding  the  scope  of  coveratc 
being  provided  and  the  specific  exclusions  which  applied.  A  good  example  of  a  separate 
software  rights  clause  can  be  found  in  the  Software  Engineering  Institute  (SEI)  Technical 
Report  CMU/SEI-86-TR-2  (Sept.,  1986).  In  fact,  the  SEI  has  several  other  reports  on 
software  which  the  council  should  examine,  including  CMU/SEI-86-TR-1  (April,  1986) 
and  CMU/SEI-87-TR-2  (January,  1987).  We  note  the  Unified  Industrial  Association  also 
made  reference  to  the  SEI  reports  at  the  January  11,  1991  Public  Hearing  on  the 
Advanced  Notice.  It  appears  to  us  little  has  been  done  to  examine  the  SETs  work  in  the 
area  of  software  rights. 
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SPECinC  COMMENTS 

(1)  Use  of  the  term  "Developed  and  Necessary".  We  see  no  difference  in  the  intent  and 

effect  of  this  term  as  used  in  52.227-14  (b)(l)(i)(B)  and  the  current  term  "Required  for 
Performance".  In  both  cases,  a  contractor’s  initiative  in  funding  development  of  a  product 
is  crushed  by  the  Government’s  insistence  that  unlimited  data  or  software  rights  pass  to 
the  Government.  We  recognize  and  suppon  the  need  for  the  Government  £o  maintain  its 
systems.  A  more  workable  alternative  than  presented  in  111. A  of  the  Advance  Notice 
overview  would  be  to  allow  the  contractor  to  retain  all  rights,  including  copyright,  for  the 
duration  of  the  contract  or  a  minimum  of  5  years.  After  5  years.  Government  purpose 
rights  could  become  effective  with  the  contractor  retaining  copyright  (license  for 
Government  use  to  be  negotiated).  This  would  allow  the  contractor  to  establish  a 
commercial  position  and  be  rewarded  for  its  investment.  The  contractor  would  also  retain 
a  potential  advantage  in  future  competitive  or  non-competitive  Government  business.  We 
believe  this  is  also  reasonable  in  exchange  for  a  firm’s  initiative  and  risk  exposure  in 
making  the  private  development  investment.  ShoMld  national  security  or  other  impelling 
interests  dictate  the  need  for  greater  rights,  license  arrangements  could  be  structured  to 
at  least  provide  t''“.  contractor  with  recovery  of  its  initial  investment  plus  a  reasonable 
profit  (royalty)  for  lost  opportunities.  Unless  the  Govemnicnt  accepts  a  more  reasonable 
policy  on  privately  funded  development,  the  contentions  between  it  and  industry  will 
continue.  More  importantly,  industry  will  no  longer  provide  its  resources  to  initiate 
development  without  at  least  a  clear  commerrial  opportunity.  Fin'»My,  since  mis 
restrictive  language  would  now  apply  to  all  agencies  (not  just  DoD),  the 

Government  at  large  will  certainly  see  less  teciuu  aMy  mnovative  solutions  and  more 

old  technology  approaches,  leaving  it  with  con  ar  growng  problems  in  system 

supportability. 

(2)  The  proposed  FAR  Part  27.4,  Subpart  27.4()6(c)  does  u.:  rporate  the  more  straightforward 
FAR  approach  to  defining  commercial  software  and  providing  more  appropriate  clause 
coverage  (52.227-19).  Unfortunately,  it  also  allows  Government  personnel  to  revert  to 
the  basic  Rights  in  Data  cl?  isc  by  itself  or  in  concert  with  52.227-19.  We  expect  the 
conservative  acquisition  profession?'  will  do  just  that,  and  continue  to  create  unnecessary 
confusion  and  contention  with  commercial  software  vendors. 

Subpart  27.406(c)  should  be  changed  to  state  that  a  commercial  software  license  will 
always  be  acceptable,  unless  it  can  be  factually  demonstrated  to  be  inconsistent  with  the 
Govemm'*’’t’s  minimum  needs  as  specified  in  the  restricted  rights  definition. 

(3)  The  proposed  FAR  Pari  27.4  does  not  clearly  describe  the  contractor’s  and  Government’s 
rights  with  respect  to  unpub’Jshed  software  existing  at  contract  award. 

The  proposed  revision  should  be  altered  to  explicitly  state  that  existing,  unpublished 
software  is  restricted  rights  software  unless  the  Government  acquires  greater  rights 
through  licensing  or  acquisition. 
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(4)  The  NASA  approach  to  encouraging  commercialization  has  been  adopted  through  the 
GPR  description  in  the  proposed  FAR,  Part  27  revision.  Under  GPR,  the  Government 
obtains  a  license  for  use  and  disclosure  relating  to  Government  purposes,  providing  the 
contractor’s  limited,  exclusive  commercial  rights  are  protected.  Unfortunately,  while  this 
change  improves  the  coverage,  the  Pan  27  revision  does  not  promote  GPR  over  unlimited 
rights.  The  positive  policy  statements  in  Subpan  27.402  are  negated  by  the  ineffective 
implementation  guidance  in  27.404. 

While  the  Government’s  intentions  are  good,  the  proposed  new  policy  statements  do  not 
encourage  commercialization  objectives  found  in  GPR  over  obtaining  unlimited  rights. 
Unless  27.404-1  is  changed  to  explicitly  favor  GPR  over  unlimited  rights.  Government 
acquisition  personnel  will  continue  to  pursue  full  rights,  and  provide  disincentives  to 
industry  to  invest  (mixed  funding)  or  participate  at  all.  We  recommend  that  27.404-1  be 
changed  to  explicitly  fwor  GPR  over  unlimited  rights. 

(5)  Subpan  27.402(c)  clearly  directs  the  Government  to  consider  not  only  shared  funding,  but 
also  its  ultimate  requirements  before  determining  appropriate  rights  to  be  acquired. 

We  believe  Subpan  27.404  should  contain  a  reference  back  to  27.402  to  assure  that  rights 
issues  will  be  properly  considered  where  mixed  funding  occurs,  and  that  GPR  will  be 
stated  as  the  most  stringent  Government  rights  possible  under  such  a  scenario. 
Furthermore,  the  contractor  should  always  be  allowed  to  claim  a  copyright  in  mixed- 
funding  situations. 

(6)  The  current  DFARS  and  FAR  automatically  allow  the  contractor  to  claim  a  copyright, 
even  when  the  Government  has  paid  for  development.  A  simple  discussion  of  why 
copyrights  are  important  is  lacking  in  the  DFARS.  • 

The  Current  FAR  27.404(f)(l)(i)  is  somewhat  better  (but  not  by  much)  in  describing  how 
the  contractor  is  normally  granted  a  copyright  to  enhance  dissemination  of  information 
produced  at  Government  expense  (i.e.,  commercialize).  The  proposed  FAR,  Part  27.4 
revision  is  a  further  improvement,  but  still  requires  enhancement  of  the  implementing 
guidance.  The  c’urent  NASA  FAR  supplement  requires  proactive  Government  team 
involvement  (including  patent  or  intellectual  propeny  counsel)  in  determining  whether  a 
contractor  has  specific  commercial  plans,  and  has  made  or  will  make  a  significant 

financial  contribution  to  the  development  or  maintenance  of  the  software.  The  proposed 
FAR,  Part  27  should  incorporate  more  of  the  NASA  supplement  language.  For  now,  the 
copyright  issue  is  most  readily  solved  by  not  invoking  today’s  Special  Works  clause  when 
the  contractor  demonstrates  a  commitment  to  commercialization.  This  will,  at  least,  give 
the  contractor  full  commercial  rights. 
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(7)  Copyrights 

(a)  While  the  DFARS  copyright  license  includes  the  right  to  distribute  copies 
to  the  public,  the  FAR  does  not,  unless  what  is  known  as  the  Special 
Works  clause  is  used. 

The  proposed  FAR,  Part  27  revision  adopts  the  current  FAR  approach, 
which  encourages  commercialization.  The  final  Pan  27  must  retain  this 
feature. 

(b)  The  FAR  approach,  which  is  more  favorable  to  industry  regarding 
commercial  exclusivity  has  been  adopted  in  the  proposed  FAR,  Part  27 
revision.  However,  copyrights,  like  unlimited  rights  and  GPR,  do  allow 
full  disclosure  for  Government  purposes.  Therefore,  the  contractor’s 
incentive  to  partially  fund  creation  of  reusable  software,  or  to  put  its  best 
talent  on  totally  government-funded  software  projects  remains  inhibited, 
since  the  current  structure  doesn’t  enable  the  contractor  to  benefit  from 
Government- sponsored  reuse  of  its  products. 

Consequendy,  a  policy  change  which  would  prevent  Government  disclosure  for  a  stated 

period  should  be  considered.  Our  comment  (1)  addresses  this  issue. 
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Analysis  of  Advanced  Notice  of  Rulemaking  for  FAR.  Part  27  and  Proposed  Changes 

The  proposed  regulatory  change  to  the  Federal  Acquisition  Regulation  (FAR):  Rights  in  Technical 
Data  -  Advanced  Notice  of  Proposed  Rulemaking,  Federal  Register,  Vol.  55,  No.  199,  15  October 
1990  proposes  to  replace  the  current  DFARS  227.4  (Interim  Rule,  1988)  and  FAR  27.4  with  a 
single  regulation  for  all  Government  agencies  addressing  rights  in  technical  data  and  computer 
software.  We  attended  the  November  19,  1990  and  January  11,  1991  public  hearings  on  this 
advanced  notice. 

By  presenting  the  regulatory  change  as  an  advanced  notice,  the  Government  has  essentially 
acknowledged  the  potential  for  extensive  comment  and  subsequent  rewrite  prior  to  publishing  the 
change  as  an  Interim  Rule.  While  comments  are  accepted  on  Interim  Rules,  historically  the  final 
product  has  been  essentially  the  same  as  the  published  Interim  Rule.  The  FAR  Council  has  not 
provided  a  timeline  for  publishing  an  Interim  Rule.  We  anticipate  that  it  will  be  at  least  12 
months  from  the  October  1990  Federal  Register  Notice. 

There  are  some  significant  changes  in  the  advanced  notice.  We  will  continue  to  focus  on  the 
impact  on  software  reuse  of  these  changes  and  any  other  proposed  modifications. 

In  combining  DFARS  227.4  and  FAR  27.4,  the  Federal  Government  has  taken  a  giant  step 
forward.  Now,  a  single  regulation  will  exist  which  addresses  the  Government’s  and  contractor’s 
rights  regarding  data  and  software.  We  thus  immediately  eliminate  present  inconsistencies 
between  the  documents.  However,  the  controversies  are  not  totally  eliminated.  In  the  following 
sections,  we  will  review  the  more  important  issues,  commenting  on  whether  any  improvements 
have  occurred  with  respect  to  reuse. 

Data  and  Software  Continue  to  be  Treated  Together 

During  the  19  November  1990  public  hearing,  the  Government  stated  that  its  decision  to  maintain 
combined  coverage  resulted  from  the  conclusion  that  there  were  more  similarities  than  differences 
in  the  topics.  However,  we  continue  to  maintain  that  the  existence  of  differences  provides 
sufficient  justification  to  separate  treatment  of  software  and  data.  Continuing  to  combine  the 
topics  unnecessarily  complicates  and  confuses  issues.  As  an  example,  Subpait  27.4  continues  to 
be  titled  Rights  in  Data  and  Copyrights  with  no  mention  of  software.  Additionally,  sections 
27.402,403  and  404  either  initially  address  only  data  or  only  include  "Data"  in  the  title  of  the 
section.  Finally,  the  phrase  "developed  and  necessary"  for  performance  is  replacing  the 
controversial  term  "required  for  performance".  When  the  phrase  is  used  in  27.404-1  (a)(l)(i)(B), 
it  initially  refers  to  data  and  software,  but  then  reverts  only  to  use  of  the  term  "data".  When  the 
phrase  is  used  in  52.227-14,  subparagraph  (b)(l)(i)(B),  the  terms  software  and  data  are  only  used 
once,  and  do  not  create  the  potential  confusion  of  whether  the  Government  intentionally  or 
unintentionally  omiued  software  in  the  second  reference  in  27.404- l(a)(l)(i)(B).  These  examples 
reinforce  our  belief  that  as  long  as  the  topics  are  addressed  together,  software  will  not  receive 
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software  will  not  receive  proper  treatment.  A  higher  degree  of  sophistication  regarding  how 
software  must  be  viewed,  with  respect  to  Government  rights  and  industry  intellectual  property 
interests  is  required.  Additionally,  a  more  focused  discussion  of  critical  software  issues,  provided 
in  a  more  readable  style  is  still  necesssary. 

Introduction  of  Government  Purpose  Rights  (GPR) 

The  NASA  approach  to  encouraging  commercialization  has  been  adopted  in  GPR.  Under  these 
circumstances,  the  contractor  is  allowed  to  retain  exclusive  commercial  rights  for  a  negotiated 
period  of  time,  after  which  the  software  or  data  reverts  to  unlimited  rights.  The  significance  of 
this  approach  is  that  the  contractor  is  provided  with  commercial  protection  in  both  mixed  funding 
and  100%  Government  funding  simations  when  it  can  demonstrate  an  intention  to  commercialize 
-  a  very  different  and  progressive  change  from  the  current  DEARS.  Under  GPR,  the  Government 
obtains  a  license  for  use  and  disclosure  relating  to  Government  purposes,  providing  the 
contractor’s  limited,  exclusive  commercial  rights  are  protected.Is  the  coverage  better?  Yes.  Is 
it  as  good  as  it  could  be?  No. 

The  DAR  Council’s  Deputy  Director,  Ms.  Linda  Greene  is  quoted  in  the  15  October  1990  issue 
of  the  Federal  Contracts  Report  (Vol.54,  No.  15,  page  549)  as  saying  "The  draft  rule  also 
establishes  more  of  a  preference  for  Government  purpose  rights  [than  unlimited  rights]  than  is 
present  under  the  [1988]  Interim  Rule.  We  think  we’ve  made  a  gigantic  stride  there." 
Unfortunately,  while  the  coverage  has  improved,  the  advanced  notice  does  iiot  emphasize  GPR 
over  unlimited  rights.  Examining  Subpart  27.404-1,  unlimited  rights,  and  27.404-4,  GPR,  reveals 
that  the  Government’s  stated  policy  is  still  to  acquire  unlimited  rights  unless  the  contract  specifies 
GPR  or  copyrights.  So,  while  intentions  are  good,  policy  statements  do  not  promote 
commercialization  objectives  found  in  GPR  over  obtaining  unlimited  rights.  Unless  27.404-1  is 
changed  to  explicitly  favor  GPR  over  unlimited  rights,  government  acquisition  personnel  will 
continue  to  pursue  full  rights  and  provide  disincentives  to  industry  to  invest  (mixed  funding)  or 
participate  at  all.  Software  reuse  is  not  incentivized  by  the  advanced  notice  policy  language, 
even  though  GPR  has  provided  a  vehicle  to  protect  commercial  rights.  The  positive  policy 
statements  in  subpart  27.402  are  negated  by  the  ineffective  implementation  guidance  in  27.404. 

Copyrights. 

The  FAR  approach,  which  is  more  favorable  to  industry  regarding  commercial  exclusivity,  has 
been  adopt^  in  the  advanced  notice.  The  Government’s  copyright  for  software  docs  not  include 
the  right  to  distribute  copies  to  the  public  as  is  now  found  in  DEARS.  This  should  help  promote 
reuse,  since  a  contractor  will  now  be  assured  that  its  full  commercial  rights  are  protected.  A 
more  proactive  Government  approach  (similar  again  to  NASA)  has  been  taken  regarding  the 
decision  process  governing  the  granting  of  contractors’  copyrights.  The  coverage  has  also  been 
improved  by  providing  a  more  complete  explanation  of  why  copyrights  arc  important 
(commercialization).  However,  copyrights,  like  unlimited  rights  and  GPR,  do  allow  full  disclosure 
for  Government  purposes.  Therefore,  the  contractor’s  incentive  to  partially  fund  creation  of 
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reusable  software,  or  to  put  its  best  talent  on  totally  Government-funded  software  projects 
remains  inhibited,  since  the  current  structure  doesn’t  enable  the  contractor  to  benefit  from 
Government-sponsored  reuse  of  its  products. 

The  issues  we’ve  identified  regarding  the  copyrighting  of  derivative  works  are  not  dispelled  by 
the  advanced  notice  coverage  in  Subpan  27.404-5  and  its  associated  clauses. 

The  issue  concerning  use  of  the  current  DEARS  Special  Works  clause  is  now  covered  in  Subpan 
27.406  and  its  associated  clause  in  52.227-17.  We  see  no  appreciable  change  beyond  a  statement 
regarding  inapplicability  to  "Limited  Rights  Data  or  Restricted  Rights  -  Software".  This  reference 
is  not  clear,  and  we  maintain  that  copyright  issues  under  27.406  will  continue  to  impact  the  DoD 
contractor  community. 

Commercial  Software 


Subpan  27.406(c)  does  incorporate  the  FAR  approach  to  defining  commercial  software  and 
providing  more  appropriate  clause  coverage  (52.227-19).  Unfortunately,  it  also  allows 
government  personnel  to  revert  to  the  basic  Rights  in  Data  clause  by  itself  or  in  concert  with 
52.227-19.  We  expect  the  conservative  acquisition  professional  will  do  just  that,  and  continue 
to  create  unnecessary  confusion  and  contention  with  commercial  software  vendors.  The  guidance 
also  negatively  impacts  commercial  software  licenses  by  noting  that  the  intent  of  52.227-19  is 
to  supersede  any  portions  of  those  licenses  that  are  inconsistent  with  Government  restricted  rights 
needs.  This  should  be  changed  to  state  that  a  commercial  software  license  will  always  be 
acceptable,  unless  it  can  be  factually  demonstrated  to  be  inconsistent  with  the  Government’s 
minimum  needs  as  found  in  the  restricted  rights  definition.  Without  this  type  of  change, 
commercial  vendors,  especia’’y  the  small  and  innovative  ones,  will  continue  to  avoid  Government 
business  because  they  will  perceive  the  Government  as  an  unfriendly  and  threatening  (loss  of 
proprietary  interests)  customer.  Once  again,  the  opportunity  for  reuse  enhancement  is  potentially 
lessened  by  what  will  be  perceived  as  a  negative  approach. 

On  balance,  the  revised  coverage  of  the  FAR  is  superior  to  that  currently  found  in  DEARS. 
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Mixed  Funding 

We  noted  that  the  DFARS  only  addresses  mixed  funding  in  the  context  of  technical  data. 
Subpart  27.402(c)  of  the  advanced  notice  corrects  this  simadon,  also  addressing  computer 
software.  It  clearly  directs  the  Government  to  consider  not  only  shared  funding,  but  also  its 
ultimate  requirements  before  determining  appropriate  rights  to  be  acquired.  It  further  directs  the 
rights  issue  to  be  addressed  at  the  lowest  possible  level  of  software  identification.  This  should 
help  focus  issues  on  particular  modules  or  components  and  narrow  contentious  areas.  We  believe 
Subpan  27.404  should  contain  a  reference  back  to  27.402  to  assure  that  rights  issues  will  be 
properly  considered  where  mixed  funding  occurs,  and  that  GPR  will  be  stated  as  the  most 
stringent  Government  rights  possible  under  such  a  scenario.  Furthermore,  the  contractor  should 
always  be  allowed  to  claim  a  copyright  in  mixed-funding  situations. 

Required  tor  Performance" 

This  term  has  been  deleted.  The  advanced  notice  now  makes  reference  to  the  concept  of 
"developed  and  necessary"  for  performance  (52.227-14(b)(l)(i)(B))  when  identifying  situations 
where  the  Government  must  obtain  unlimited  rights.  The  advanced  notice  states  a  belief  that  this 
change  has  narrowed  the  application  of  the  concept,  but  we  do  not  agree.  We  see  no  change  of 
any  significance  in  the  new  52.227-14  (b)(l)(i)(B),  when  compared  to  DFARS  227.471  and 
252.227-7013  language.  Since  the  advanced  notice  gives  no  further  explanation  or  example  to 
clarify  how  this  "narrowing"  has  occurred,  we  suspect  there  is  more  show  than  substance  in  the 
claim.  Another  concern  of  even  greater  importance  is  the  fact  that  the  offensive  DFARS 
language  is  now  proposed  for  use  throughout  the  Federal  Government.  Without  deletion  or 
radical  modification,  all  federal  agencies  will  now  face  the  same  contention  existing  today 
between  industry  and  the  DoD. 

This  "required  for  performance"  issue  continues  to  be  the  most  significant  potential  impediment 
to  software  reuse.  Industry  will  not  provide  its  own  products  or  use  its  best  talent  when  faced 
with  loss  of  its  competitive  position  within  the  commercial  and  Government  markets.  While  the 
Government  can  foster  reuse  through  its  own  funding  for  new  software,  it  continues  to  lose 
potential  reuse  opportunities  derived  from  use  of  industry-funded  software. 

The  concept  should  be  changed  to  allow  for  more  favorable  industry  treatment  A  change  in 
wording  which  would  allow  contractors  to  retain  rights  for  the  duration  of  the  contract  (or  a 
minimum  of  5  years)  might  be  sufficient  to  overcome  this  impediment.  We  will  continue  to 
explore  this  potential  solution. 
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Conclusion 


We  have  addressed  the  most  significant  potential  changes  for  software  reuse  in  the  advanced 
notice  of  rulemaking.  Overall,  it  is  a  more  understandable  treatment  of  rights  in  data  and 
software,  though  the  basic  Rights  in  Data  clause  remains  horrific  in  its  length  and  treatment  of 
a  multitude  of  issues. 
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